Как правильно писать тесты?

Question

[Tsiren Naimanov]

Добрый день!
Недавно начал писать тесты, и столкнулся с такой траблой...
Как правильно писать тесты?
В разных статьях, особенно на хабре, что тесты должны полностью покрыть код и т д
Но как формировать тестовые методы?
Например у меня есть аналог контекста данных (EF) с фэйковыми DbSet
Сущностей например 5
Как оформлять тесты?)
Я могу конечно все тесты написать в 1 методе, но это будет оч не красиво...
Так по какой же логике оформлять?
Например:

AddData_ShouldReturnSomethingRight()
AddData_ShouldReturnAllRight()
AddData_ShouldReturnError()
AddData_ShouldReturnException()

или например так:

AddData_ShouldReturnSomethingRight()
AddData_ShouldReturnErrorOrException()

Answer 1

[Дмитрий]

1. Начните читать книгу Роя про "Art of Unit testing" уже есть 2 редакция
2. Прочитайте комментарий на ru_SO

теперь касательно ваших методов. К примеру я увидел такой лог выполнения тестов:

AddData_ShouldReturnError() - Failed
AddData_ShouldReturnException() - Failed

Что должен заключить из этих ошибок?

Пытаюсь читать название теста: "Метод AddData должен вернуть ошибку".
Что произошло мне непонятно. Одни вопросы:
* Какие тестовые данные подаются?
* Какое вообще исходное состояние?
* Что принято считать ошибкой? Может быть запись в логе об ошибке, а может быть некорректное значение возвращаемое методом? А может метод должен возвращать False в случае ошибки?

Вот пример, к чему нужно стремиться:

InvalidAdminToken_UsersRequest_ListIsEmpty

Название теста следует схеме именования:

[When]_[Act]_[Then]

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

Если вдруг упало, то вы сразу поймете, что список не пустой! Потому что тестовый метод содержит только и только assert-ы, таким образом ваш тестируемый код выполняемый в Act-части неверный!

*UPD*

Любой модульный тест должен работать согласно паттерну проектирования AAA - Arrange -> Act - > Assert. Т.е. Подготовка к тестированию - Выполнение проверяемого кода - Проверка результатов.

Технически работа модульного теста организовывается так:

setUp() - это подготовка к тестированию, т.е. Arrange
test() - Здесь Act и Assert

Да, в модульном тесте подготовка пишется только и только в setUp() методе! Ошибка в подготовке тест-среды не должно влиять на сам тестовый метод.

Тестовый метод это не подготовка результата, это проверка РАБОТЫ вашего БОЕВОГО кода.
Это важно. Очень часто вижу, когда в тест-методы суют небольшие куски кода подготавливающие тест.данные. Это неправильно!!!

Тестовый метод это:
Первым делом выполнить боевой код. Ради него радимого и пишется тестовый метод.
Вторым делом один assert . Да, тестовый метод должен содержать ТОЛЬКО и только одну проверку!

Другими словами не должно быть такого:

assertTrue(usersList is not None)
assertTrue(usersList.isEmpty)

Comments

[Tsiren Naimanov]

Спасибо :)
обычно я заполняю данные через конструктор тестируемого объекта...

[Дмитрий]

Tsiren Naimanov: Да, но это должно происходить не в тестовом-методе!

[Tsiren Naimanov]

Дмитрий: например дефолный метод
Act [TestMethod]
public void Index()
{
// Arrange
HomeController controller = new HomeController(new MyLogicObj);

// Act
ViewResult result = controller.Index() as ViewResult;

// Assert
Assert.IsNotNull(result);
}
в инициализации arrange у меня есть конструктор который принимает некий интерфейс IInterfaceLogic

[Дмитрий]

Tsiren Naimanov: Программист - это специалист применяющий мозг! Ога? Искренне Ваш К.О. Я к тому, что все что делается по-умолчанию не всегда является лучшим решением.

[Tsiren Naimanov]

Дмитрий: хорошо :)

Answer 2

[Anton]

Используй подход TDD и будет тебе счастье.

Answer 3

[V Sh.]

Почитайте книжку

Comments

[V Sh.]

ссылка на pdf. Книжка авторства Бека "Экстремальное программирование: разработка через тестирование".

[Tsiren Naimanov]

V Sh.: пусто там 404

Answer 4

[Дмитрий Макаров]

Я помню, у меня тоже возник такой вопрос. Везде говорят: пишите тесты, код должен быть тестируемым....и тпх. Попробовал писать тесты и особо не проникся. Но все равно читал разные источники, набиралась критическая масса знаний по тестированию.
Ключевым моментом стала книжка Марк Симан. Внедрение зависимостей в .NET. В первой части подробно описывается, что такое зависимости, как и зачем их внедрять. И после этого стало все кристально ясно.
Код должен быть готов к тестам. Код должен быть модульным. Зависимости должны внедряться через интерфейсы, тогда в тестах тестируемому коду можно будет подсунуть любую ромашку, если она соответствует интерфейсу. И вот уже потом можно осваивать/придумывать стратегии тестирования, наименования тестов, логи, автоматический запуск, анализ покрытия и тд.