SergunkaОткрываешь Jiru там уже написана задача к примеру на спринт т.е. 2 недели

1) видишь описание бизнес кейса т.е. преполагается, что это фича пришла от продакт оунера
2) тут же расписан твой тест кейс на Cucumber
3) Acceptance criteria

Копируешь огурец в тест - и потихоньку начинаешь кодить последовательно. Тест прошел задача практически выполнена.

... skipped

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

SergunkaПриведите свой пример с интересом сравним.Вы там вместе с Petro123 сидите чтоли? чуть что, так сразу пример подавай. Я вот могу рассказать почему ваши тесты плохие.

SergunkaРасскажите, не надо стеснятся Тут народ уже 7 страниц спорит о том, что тесты вроде как хорошая штука, вот только они должны быть по делу, а не просто для увеличения покрытия, потому что последняя метрика в действительности мало о чемвообще ни о чем не говорит, потом вы приходите весь в белом и говорите: эй, пацаки, тут есть подход fucking around driven development - там уже все продумано за вас, есть аж специальный DSL, нужно только реализовывать то что в жире написали и все будет хорошо. Ну давайте посмотрим на ваш cucumber...

Сценарий:


"Реализация":



Ну, во-первых, никакого DSL какбы и нет - ну позволяет оно каким-то образом параметризовывать (у вас зачистку тестовых данных перед выполнением сценария не увидел, но будем считать что оно может иметь место) тесты через регулярные выражения (буэээ) и какие-то простенькие списки pojo (что если перед тестом нужно мегабайт сильно связных данных в базу пролить?) и на этом все, зато разработчик этих "сценариев" начинает чувствовать себя не обезьяной, а чем-то большим

во-вторых, помимо того, что нужно писать сами тесты, добавляется еще обязанность писать всю эту обвязку к cucumber, при этом очевидно, что все будущие потребности "сценариев" с первого раза не покрыть, поэтому эту лапшу придется постоянно переписывать (есть мнение, что если придется тестировать граничные случаи, то cucumber будет только мешаться)

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


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

Leonid KudryavtsevRegression Test ?
Если кто-то поступил по своему и это сломало "наложения прежних времен", то сразу должно быть видно.Вы про что вообще? Регрессионное тестирование - оно всегда ручное, тут же автоматизацию обсуждают.

Leonid KudryavtsevИли у нас разные понятия о термине "регрессионное тестирование"Не знаю какие там у вас понятия, но в этом топике обсуждается наполнение каталога src/test - там нет регрессионных тестов: все что там есть запускается разработчиком или CI, регрессионное тестирование отдается полностью на откуп QA - это соседний форум.