SergunkaИными словами Вам удалось освоить JUnit test... поздравляю нормальный результат... есть куда рости Нет там JUnit никакого, просто показано как правильно реализовывать проверки, едем дальше:




Смотрим что такое Customer:




ой. Получается, что в сценарии вас просят работать с именем, а вы вместо этого работаете с assetId и при этом все "зеленое", более того, контракт на заполненность имени нигде не форсируется и не проверяется, зато тесты зеленые, ревью делать не нужно - можно сразу в прод засылать. Еще один плохой момент в реализации ваших тестов: если разработчику понадобится переименовать поля pojo, то тестовые сценарии не развалятся - геттеры и сеттеры переименует IDE, а вот в cucumber как торчали "customer with name" так останутся торчать.

В целом, подход что вы описываете, а именно:

SergunkaДавайте опять про то как должно быть.

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

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

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


Вообще никакого отношения к разработке не имеет: существует какое-то преклонение перед BDD, в процессе этого преклонения создаются какие-то артефакты, но толку от них нет никакого просто потому что сам по себе процесс дырявый. И беда не в том, что BDD плохой (хотя этот DSL нужно поддерживать, что печально), а в том что вы неправильно его применяете:
тесты должны разрабатываться (или хотябы рецензироваться) людьми, которые этим профессионально занимаются, подход типа "вот сделай фичу и сам покрой его тестами" много где имеет место быть, но в целом он неправильный (ваши корявые реализации тому подтверждение)

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

Leonid Kudryavtsevдело не в узко, а в том, что я тогда вообще не понимаю, что у людей лежит в src/test )))

Для меня, src/test в первую очередь "проверка того, что не нарушилась работоспособность работающей ранее функциональности, если её код мог быть затронут при исправлении некоторых дефектов в другой функциональности" ( C ) wikiНу давайте поразмыслим вместе. То что лежит в src/test относится к так называемому white box testing, т.е. в абсолютном большинстве это или юнит-тесты, или интеграционные, которые в свою очередь реализуют разработчики (ну или люди, обладающие скилом разработчика). Вот вам нравится цитировать википедию, а там в той же статье написано:wikiIn the corporate world, regression testing has traditionally been performed by a software quality assurance team after the development team has completed work. However, defects found at this stage are the most costly to fix. This problem is being addressed by the rise of unit testing. Although developers have always written test cases as part of the development cycle, these test cases have generally been either functional tests or unit tests that verify only intended outcomes. Developer testing compels a developer to focus on unit testing and to include both positive and negative test cases.И вот в разрезе юнит-тестов (т.е. там где мы тестируем небольшие участки кода), я как-то слабо себе представляю наличие регрессий:

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

Т.е. получается так, что там где мы действительно можем (и должны) проверить наличие (или отсутствие) регрессий - это либо интеграционные тесты, либо "ручное тестирование" (т.е. то что делает команда QA, руками они это делают или нет - не суть важно) и здесь начинаются "приколы", которые мало зависят от разработчика, а именно:

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