Последние комментарии

Евгений

Очень справедливые размышления.

Показать - не значит дать пощупать.

Михаил Фленов

Я не заметил цепочки. Есть один модуль с одним классом, который называют крутым словом engine, но он простой - запрос на получение людей, которые сделали какое-то действие. Да, у меня есть подготовительные вещи, типа создания определения, но я даже не проверяю, правильно ли создана конфигурация. Я прогоняю один и тот же метод Process в одном и том же классе, который назвали XXXXPromotion несколько раз и смотрю результат в одном и том же тесте. Там есть и другие XXXXPromotion классы с таким же Process методом, которые делают примерно подобные вещи. Но факт остается фактом, что я тестирую один метод.

Можно создать несколько тестов, каждый из которых будет прогонять метод Process по одному разу (хотя тест на дубликаты все же вынужден будет выполнять дважды), а можно обойтись одним тестов.

Overdrive

2Михаил Фленов
Так это уже интеграционный тест. Юнит тест когда проверяется только один модуль и только его функциональность и зависимые объекты поменяются моками в DI контейнере. А так ты получается тестируешь всю цепочку бизнес-логики. Если у приложения плохой дизайн, обычно проблематично написать юнит тесты, и в основном пишутся одни интеграционные.

Михаил Фленов

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

На примере уже упомянутого мной промоушн движка, как я тестирую простой success path:

1. Создать транзакцию
2. Truncate table с действиями пользователя
3. Создать объявление промоушена
4. Прогнать промоушн
5. Assert на результирующие данные, чтобы убедится, что никто не получил призов, ведь действий пользователя нет
6. Добавить действия
7. Прогнать промоушн и убедится, что приз получен
8. Прогнать промоушн и убедится, что нет дубликата

Кто-то может сказать, что я тестирую три разве вещи:
1. Никто не получает при отсутствии данных
2. Реальный success path
3. Тест на дубликат

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

Ну в конце у меня конечно же rollback и ничего в базе не остаётся.

he

Как я делаю : ставлю столка ассерт штоби легко можна понят где ошибка. Если из теста трудно понят где ошибка, тест нада изменит

Kastor

Asserts может быть несколько, но они должны тестировать один сценарий.
Главное правило такое - упал один тест - у нас одна проблема. Упало два теста - две проблемы.

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

А еще мне показалось, что у тебя одни тесты зависят от других. Так ли это?

Михаил Фленов

Ну я тоже покупал специальный лак супер стойкий, так что надеюсь, что выдержит. Если что, потом еще слой доложим.

Radekk

Мне сначала показалось что это морилка. Лестница может так довольно скользкой получиться.
А лаку потом плохо не будет от влажной уборке? Я паркет когда лакировал выдали какой-то специальный влагостойкий, а то предыдущий почти смылся с паркета.
Запилите уже тогда что-нить типа "Борщ глазами хакера" )))

Михаил Фленов

Ширина вполне нормальная, но дочка у меня уже скатилась по ней на попе.