Как я могу заставить мои модульные тесты провалиться, если я добавлю что-то в свой код? - PullRequest
0 голосов
/ 26 мая 2009

Я хочу, чтобы мои юнит-тесты покрывали мои POCO.

Как мне их проверить?

Что если я добавлю новое свойство? Как сделать мой тест неудачным?

Тестирование свойств и методов, которые я знаю, но проблема в том, как убедиться, что мои тесты не пройдены, если что-то добавлено в мои документы.

Ответы [ 5 ]

4 голосов
/ 26 мая 2009

Тестирование - это проверка того, может ли написанное делать то, что должно, ни больше, ни меньше. Поэтому, если вы пишете какой-то код, вы делаете это по определенной причине. Ваши тесты должны отражать, что код действительно соответствует причине, для которой вы написали код. Вот и все, больше ничего нет. И.о .: Если вы пишете несколько классов, вы должны проверить, правильно ли написанное вами поведение по сравнению с тем, что должно делать поведение.

3 голосов
/ 26 мая 2009

Из прочтения вашего вопроса вы либо неправильно понимаете, что такое POCO, либо неправильно понимаете модульное тестирование.

POCO - это просто старомодный объект. У него есть состояние и поведение. Вы проводите модульное тестирование состояния, помещая (устанавливая) значения в свойства и утверждая, что значение соответствует ожидаемому. Вы тестируете поведение модуля, утверждая ожидания в отношении методов.

Вот упрощенный пример POCO и его тестов. Обратите внимание, что тестового кода больше, чем кода реализации. Когда модульное тестирование выполнено правильно (TDD), это так.

public class Person
{
    private Name name = Name.Empty;
    private Address address = Address.Empty;
    private bool canMove;

    public Name Name
    {
        set { name = value; }
        get { return name; }
    }

    public Address Address
    {
        private set { address = value; }
        get { return address; }
    }

    public bool CanMove
    {
        set { canMove = value; }
        get { return value; }
    }

    public bool MoveToNewAddress(Address newAddress)
    {
        if (!CanMove) return false;
        address = newAddress;
        return true;
    }
}

[TestFixture]
public class PersonTests
{
    private Person toTest;
    private readonly static Name NAME = new Name { First = "Charlie", Last = "Brown" };
    private readonly static Address ADDRESS =
        new Address {
            Line1 = "1600 Pennsylvania Ave NW",
            City = "Washington",
            State = "DC",
            ZipCode = "20500" };

    [SetUp]
    public void SetUp()
    {
        toTest = new Person;
    }

    [Test]
    public void NameDefaultsToEmpty()
    {
        Assert.AreEqual(Name.Empty, toTest.Name);
    }

    [Test]
    public void CanMoveDefaultsToTrue()
    {
        Assert.AreEqual(true, toTest.CanMove);
    }

    [Test]
    public void AddressDefaultsToEmpty()
    {
        Assert.AreEqual(Address.Empty, toTest.Address);
    }

    [Test]
    public void NameIsSet()
    {

        toTest.Name = NAME;
        Assert.AreEqual(NAME, toTest.Name);
    }

    [Test]
    public void CanMoveIsSet()
    {
        toTest.CanMove = false;
        Assert.AreEqual(false, toTest.CanMove);
    }

    [Test]
    public void AddressIsChanged()
    {
        Assert.IsTrue(toTest.MoveToNewAddress(ADDRESS));
        Assert.AreEqual(ADDRESS, toTest.Address);
    }

    [Test]
    public void AddressIsNotChanged()
    {
        toTest.CanMove = false;
        Assert.IsFalse(toTest.MoveToNewAddress(ADDRESS));
        Assert.AreNotEqual(ADDRESS, toTest.Address);
    }
}

Чтобы сначала выполнить тест, заглушите методы или свойства, но не реализуйте никакого поведения. Запустите тесты, посмотрите, как они провалились, затем добавьте в поведение по одной строке за раз, пока она не пройдет. Как только это пройдет, остановитесь. Не пишите больше кода, если вы не пишете больше тестов (если вы не рефакторинг, в этом случае вы не добавляете поведение).

1 голос
/ 26 мая 2009

Возможно, под POCO вы подразумевали DTO, и в этом случае ответом будет:

Нет, вам не следует проверять свои DTO - скорее, тестируйте сервисы, которые работают с ними.

1 голос
/ 26 мая 2009
  1. Я считаю, что вы не должны проверять фреймворк вместе с вашим собственным кодом например, если у вас есть авто сгенерированное свойство как это:

    public string Name
    {get;set;}
    

    нет необходимости проходить тест способ проверить, работает ли он нормально.

  2. Вы не должны проверять внутреннее состояние своего класса, вместо этого вы должны проверять его поведение.
  3. Иногда (некоторые могут сказать всегда) лучше написать тест перед написанием кода. Таким образом, вы должны понять, что вы хотите сделать, вместо того, чтобы понимать, как это сделать (этот подход называется разработкой, управляемой тестом) 1011 *

Вот цикл TDD:

  • Напишите тест и получите красный сигнал
  • Напишите код и получите зеленый сигнал
  • Измените код, и вы должны получить зеленый сигнал
1 голос
/ 26 мая 2009

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

Или ...

Запуск метрик покрытия кода как часть сборки. Они будут указывать, был ли добавлен кодовый газ, но не подпадают под испытания.

Или ...

Запустите мутационные тесты как часть сборки. Они укажут, выполняются ли какие-либо тесты, которые охватывают код, и фактически ничего не тестируют.

Или все вышеперечисленное.

...