Как вы расширили свой класс Assert?

Ответ 1

Я только что добавил реализацию в ImageAssert, как я писал выше (в моем вопросе) Я был бы рад услышать больше примеров такого рода

[TestMethod]
public void CompareImagesSize()
{
 Image expected = Bitmap.FromFile(@"C:\ShaniData\Projects2008\TddSamples\Output\ExpectedImage.png");
 Image actual = Bitmap.FromFile(@"C:\ShaniData\Projects2008\TddSamples\Output\RhinoDiagram.png");

 Bitmap expectedBitmap = new Bitmap(expected);
 Bitmap actualBitmap = new Bitmap(actual);

 ImageAssert.HasTheSameSize(expectedBitmap, actualBitmap);
}

[TestMethod]
public void CompareTwoSameImagesButWithDifferenExtension()
{
 Image expected = Bitmap.FromFile(@"C:\ShaniData\Projects2008\TddSamples\Output\Image2.png");
 Image actual = Bitmap.FromFile(@"C:\ShaniData\Projects2008\TddSamples\Output\Image1.jpg");

 Bitmap expectedBitmap = new Bitmap(expected);
 Bitmap actualBitmap = new Bitmap(actual);

 ImageAssert.AreEqual(expectedBitmap, actualBitmap);
}

public class ImageAssert
{
    //public static void MoreMethods(Bitmap expected, Bitmap actual)
    //{
    //    //Compare image extensions
    //    //Compare Thumbnail...
    //}

    public static void HasTheSameSize(Bitmap expected, Bitmap actual)
    {
        if ((expected.Height != actual.Height)
            || (expected.Width != actual.Width))
            HandleFail("ImageAssert.HasTheSameSize", String.Empty);
    }

    public static void AreEqual(Bitmap expected, Bitmap actual)
    {
        for (int i = 0; i < expected.Width; i++)
        {
            for (int j = 0; j < expected.Height; j++)
            {
                Color expectedBit = expected.GetPixel(i, j);
                Color actualBit = actual.GetPixel(i, j);
                if (!expectedBit.Equals(actualBit))
                {
                    HandleFail("ImageAssert.AreEqual", String.Empty, i, j);
                    return;
                }
            }
        }
    }

    internal static void HandleFail(string assertionName, string message, params object[] parameters)
    {
        throw new AssertFailedException(String.Format(assertionName));
    }
}

Ответ 2

Мне нравится ощущение класса Assert, но хотелось получить то, что будет служить общей основой для проверки. Я начал с Roger Alsing статью об использовании методов расширения и теперь имеет систему, которая работает как:

Enforce.That(variable).IsNotNull();
Enforce.That(variable).IsInRange(10, 20);
Enforce.That(variable).IsTypeOf(typeof(System.String));
etc.

Если какое-либо принуждение не выполняется, оно выдает исключение. Я рассматриваю рефакторинг, чтобы я мог также включить некритическую оценку, которая не генерирует исключения. Некоторые вроде Check.That как вариант Enforce.That, которые возвращают логические значения, но имеют методы расширения с идентичными сигнатурами.

Что мне нравится в этом подходе до сих пор, так это то, что я могу использовать их в своих модульных тестах, а также для проверки и проверки после проверки в моем фактическом коде без ссылки на Microsoft.VisualStudio.QualityTools.UnitTestFramework сборка. Я поместил его в свою сборку корня для своей инфраструктуры приложений, а Enforce находится в корне, поэтому очень легко добраться.

Ответ 3

Что мое решение:

using MyStuff;

using A = Microsoft.VisualStudio.TestTools.UnitTesting.Assert;

namespace Mytestproj.Tests
{
    public static class Assert
    {
        public static void AreEqual(object expected, object actual)
        {
            A.AreEqual(expected, actual);
        }

        // my extension
        public static void AreEqual(MyEnum expected, int actual)
        {
            A.AreEqual((int)expected, actual);
        }

        public static void IsTrue(bool o)
        {
            A.IsTrue(o);
        }

        public static void IsFalse(bool o)
        {
            A.IsFalse(o);
        }

        public static void AreNotEqual(object notExpected, object actual)
        {
            A.AreNotEqual(notExpected, actual);
        }

        public static void IsNotNull(object o)
        {
            A.IsNotNull(o);
        }

        public static void IsNull(object o)
        {
            A.IsNull(o);
        }
    }
}

Ответ 4

Многие мои тесты вращаются вокруг загрузки объекта (например, CuttingPath) с известным хорошим состоянием. Выполнение теста, а затем сравнение результата с загруженным объектом. Если они отличаются, то что-то "случилось", чтобы вызвать изменение кода.

Этот подход экономит массу времени и позволяет при необходимости настраивать сравнение.

Ответ 5

Я думаю, что если вы реорганизовываете свои тесты для уменьшения дублирования, вы в конечном итоге создаете свою собственную инфраструктуру как побочный продукт, и, конечно же, ваша тестовая структура будет содержать вспомогательные помощники, которые имеют смысл в вашем контексте.

Примером, который я имел в виду, было то, что при тестировании отчета xhtml мы завершили тесты, которые выглядели примерно так:

  assertCoverageEquals(45.5);

где позади утверждения было что-то вроде:

  assertPercentage(COVERAGE_ID, 45.5);

а затем за этим было что-то, что использовало xpath для получения значения и другого метода, который знал, что форматирование было для процентов.