1) ожидаем (подписываемся) какой-то event (в общей куче), как критерий прохождения теста.
2) вызываем функцию, которую т.н. "тестируем", которая вроде бы должна отправить тот event.
3) контрольный выстрел- из теста отправляем event, ожидаемый в (1).
Тест всегда проходит, похрен что "тестируемая" функция совсем иначе себя ведёт. И вот этому тесту был посвещен целый тикет в жыре.
Здравствуйте, Тёмчик, Вы писали:
Тё>1) ожидаем (подписываемся) какой-то event (в общей куче), как критерий прохождения теста. Тё>2) вызываем функцию, которую т.н. "тестируем", которая вроде бы должна отправить тот event. Тё>3) контрольный выстрел- из теста отправляем event, ожидаемый в (1).
Тё>Тест всегда проходит, похрен что "тестируемая" функция совсем иначе себя ведёт. И вот этому тесту был посвещен целый тикет в жыре.
Это реальная и повсеместная проблема. В текущей команде я лекцию делал по юнит тестам с разяснениями почему подобные тесты не вариант и как надо делать. Вроде помогло. Как еще с таким бороться я не знаю
Здравствуйте, Тёмчик, Вы писали:
Тё>Как относитесь к такой практике юнит тестов:
Тё>1) ожидаем (подписываемся) какой-то event (в общей куче), как критерий прохождения теста. Тё>2) вызываем функцию, которую т.н. "тестируем", которая вроде бы должна отправить тот event. Тё>3) контрольный выстрел- из теста отправляем event, ожидаемый в (1).
Тё>Тест всегда проходит, похрен что "тестируемая" функция совсем иначе себя ведёт. И вот этому тесту был посвещен целый тикет в жыре.
Тё>Пригорело. Опять.
Хех, индийские аутсорсеры миллионы зарабатывают такими тестами, это серьезный бизнес
Здравствуйте, Тёмчик, Вы писали:
Тё>Тест всегда проходит, похрен что "тестируемая" функция совсем иначе себя ведёт. И вот этому тесту был посвещен целый тикет в жыре.
А почему это не было поймано на этапе code review?
Здравствуйте, blacktea, Вы писали:
B>А почему это не было поймано на этапе code review?
А с чего должны быть такие гарантии? А за коде-ревьювером нужен еще кто-то, кто оценит его работу?
Здесь первичным должно быть четкое распределение личной ответственности и последствия за грубые нарушения в работе.
Тот, кто пишет тесты — должен понимать, что его работа имеет четкие критерии качества. А именно — если в следующий этап тестирования или еще хуже в продакшн пролезет ошибка, которую закрывали этим тестом, да еще пролезла в результате подделки юнит-теста — то будут финансовые последствия (лишение премии например, а повторное — до увольнения).
Это основной каркас в обеспечении качества. А коде-ревью — такое специфичное субъективное действо...
Здравствуйте, Тёмчик, Вы писали:
Тё>Как относитесь к такой практике юнит тестов:
Тё>1) ожидаем (подписываемся) какой-то event (в общей куче), как критерий прохождения теста. Тё>2) вызываем функцию, которую т.н. "тестируем", которая вроде бы должна отправить тот event. Тё>3) контрольный выстрел- из теста отправляем event, ожидаемый в (1).
Тё>Тест всегда проходит, похрен что "тестируемая" функция совсем иначе себя ведёт. И вот этому тесту был посвещен целый тикет в жыре.
Тё>Пригорело. Опять.
просто новый тикет в жире не должен оцениваться как полезная работа — это тех долг
классика же ж
Здравствуйте, blacktea, Вы писали:
B>А почему это не было поймано на этапе code review?
Это полу-политический вопрос. Лично я UT в 90% случаев прокручиваю, неглядя. Так что разводить вонь по этому поводу- ну, в рсдн только насрать.
А в этом случае пригорело по причине массированного рефакторинга, и выбор —
1) тоже фейк вкрутить (а это значит, нарушить собственные принципы)
2) починить- срываются сроки, пригар
3) отключить, ибо хуже не будет.
Здравствуйте, Тёмчик, Вы писали:
Тё>Это полу-политический вопрос. Лично я UT в 90% случаев прокручиваю, неглядя. Так что разводить вонь по этому поводу- ну, в рсдн только насрать. Тё>А в этом случае пригорело по причине массированного рефакторинга, и выбор —
Ну вот, если сам и проглядел во время code review, то как говорится ССЗБ
А вообще, я сам часто так халтурю. Не вчитываюсь, смотрю чисто на соответствие CC. Потом в какой-то момент смотришь на кодовую базу и ужасаешься. Видимо пора перестать халтурить на code review.
KP>Это реальная и повсеместная проблема. В текущей команде я лекцию делал по юнит тестам с разяснениями почему подобные тесты не вариант и как надо делать. Вроде помогло. Как еще с таким бороться я не знаю
это не халтура, а использование инструмента не к месту.
любой тест, в т.ч. юнит-тест пытается зафиксировать контракт какого-то кода.
если люди пишут бессмысленный юнит тест — значит никакой контракт они фиксировать не хотят, нечего их насиловать.
если критично — надо отдать написание теста человеку, который понимает, какой здесь контракт нужен и почему.
а то и вообще не писать этот тест.
Здравствуйте, Тёмчик, Вы писали:
Тё>Тест всегда проходит, похрен что "тестируемая" функция совсем иначе себя ведёт. И вот этому тесту был посвещен целый тикет в жыре.
Юнит тесты не нужны.
1) Объем кода юнит-тестов при полном покрытии превышает объем кода
2) Юнит-тесты мешают рефакторингу, изменение структуры кода часто сильно рушит юнит-тесты.
3) Очень часто встречаются юнит-тесты, которые фактически ничего не проверяют.
G>1) Объем кода юнит-тестов при полном покрытии превышает объем кода G>2) Юнит-тесты мешают рефакторингу, изменение структуры кода часто сильно рушит юнит-тесты. G>3) Очень часто встречаются юнит-тесты, которые фактически ничего не проверяют.
Здравствуйте, Ватакуси, Вы писали:
G>>1) Объем кода юнит-тестов при полном покрытии превышает объем кода G>>2) Юнит-тесты мешают рефакторингу, изменение структуры кода часто сильно рушит юнит-тесты. G>>3) Очень часто встречаются юнит-тесты, которые фактически ничего не проверяют.
В>Это всё так. Но какая альтернатива?
Интеграционные, функциональные тесты. Design by contract, типизация, статичские верификаторы.
По моему опыту статическая ферификация на предмет самых популярных ошибок дает самый лучший результат.
это всегда вопрос соотношения цены и качества.
важный и сложный кусок кода, упростить не получается, интеграционные тесты до него дотягиваются через 100 посредников — ну что поделаешь, юнит тест будет выгоднее.
подавляющее большинство кода просто не стоит этих усилий, да и интеграционные тесты масштабируются лучше — ими занимаются QA, но бывают же исключения.
Здравствуйте, landerhigh, Вы писали:
G>>2) Юнит-тесты мешают рефакторингу, изменение структуры кода часто сильно рушит юнит-тесты.
L>Высококвалифицированный хирург поможет плохому танцору!
Не понял, поясни мысль. Ты хочешь сказать, что рефакторинг не инвалидирует юнит-тесты?
