Модульное тестирование в C # - следует ли вам проводить модульное тестирование в производном классе, о котором заботятся в базовом классе?

Question

public class Foo<T>
{
    public Foo(Bar bar)
    {
        if (bar == null) throw new ArgumentNullException("bar");
    }
}

public class Foo : Foo<Object>
{
    public Foo(Bar bar) : base(bar) { }
}

В принципе, я понимаю, что мне следует выполнить модульное тестирование конструктора для Generic Foo. Должен ли я также протестировать конструктор для неуниверсальной версии? Причина, по которой я спрашиваю, заключается в том, что исключение выдается на уровне универсального конструктора ...

[TestMethod]
[ExpectedExeption(typeof(ArgumentNullException))]
public void GenericFooNullArgumentInConstructor()
{
    var foo = new Foo<int>(null);
}

//Is this test necessary?
[TestMethod]
[ExpectedExeption(typeof(ArgumentNullException))]
public void NonGenericFooNullArgumentInConstructor()
{
    var foo = new Foo(null);
}

Answer 1

Да. Не глядя на все реализации, это самый простой способ проверить, что ваши производные классы сохранили гарантии вашего базового класса. Особенно, когда Боб, стажер, приходит позже и модифицирует ваш производный класс, чтобы сделать что-то еще.

Answer 2

Одним словом: да.
Ключевым моментом здесь является regression - вы будете писать модульные тесты для проверки вашей текущей реализации (или даже до реализации, если вы TDD), но также вы будете писать ее, чтобы защитить себя от критических изменений кода в будущем.
Поскольку и базовый, и подкласс могут быть изменены в будущем - оба должны быть проверены.

Answer 3

Это зависит ...

почему вы пишете модульные тесты?

1) для проверки кода, который вы собираетесь написать

2) для проверки кода, который вы уже написали

3) для проверки кода, который кто-то может написать в будущем

Если вы пишете код для проверки чего-либо, выВы собираетесь писать, напишите его в соответствии с требованиями кода, который вы собираетесь писать.

Если вы пишете тесты для тестирования своего кода, протестируйте код, который вы пишете.

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

Пример

У вас есть базовый класс A с определенным методом, M.Вы проверили этот метод задом наперед, вбок и вверх ногами.Затем вы создаете 3 подкласса A и называете их B, C и D. Вы добавляете новые функциональные внутренние методы для классов B и C.

Вы должны протестировать новые методы классов B и C, потому что этокод не протестирован, но метод M из класса A. уже протестирован.

Вы переопределяете метод M в классе D, добавляете код, а затем вызываете базовый метод M. Новый метод переопределения должен быть протестирован, и ондолжен рассматриваться как совершенно новый метод.Модульный тест не может подтвердить, что был вызван метод базового класса M.

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

Бессмысленно сдавать один и тот же экзамен три раза подряд.

С другой стороны

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

Answer 4

Вы должны написать модульные тесты и для производного класса! Модульные тесты гарантируют, что тестируемый класс работает так, как вы ожидаете. Это дает вам возможность изменить его когда-нибудь. Если тогда вы сделаете ошибку при рефакторинге конструктора производного класса - ни один модульный тест не найдет эту ошибку. (Если вы не написали модульные тесты для производного класса).