42

сначала код, потом тесты? интересно
tdd
как можно писать код и "потом понять что я тестирую", это как так? или лыжи не едут

отлично! осталось узнать вопрос

если даже "размытые требования", должен же быть какой-то DoD

вот ttd бы сразу бы завернуло написание кода, потому что тест написать нельзя, сплошная польза

как всё происходило:
1) была задача, очень обтекаемая, с бедными требованиями
2) я взял её в работу, потому что надо. требования или их подобие я дособирал по частям у разных людей в процессе разработки
3) я получил решение которое субъективно делает то что нужно согласно информации которую я знаю

теперь нужно как то на основе информации которая есть у меня, по сути неформально описанные функциональные требования, получить тесты, да ещё и не бесполезные, хотя критерием оценки стратегии тестирования на данный момент является процент покрытия и больше ничего. DoD отсутствует, по сути он на моей совести

надо было делать все наоборот

не, стоп, dod есть, хоть он и на твоей совести
заказчик же что-то хочет и как-то будет валидировать то, что ты сделал?
вот и тестируй это, хотя бы, а юнитами можно потом обмазаться

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

я бы и рад завернуть задачу, но она от этого быстрее не сделается

почему?

кажется, что если принесут более-менее понятное, то и делать будешь более-менее понятное, а это быстрее

ещё, интересно, когда всё горит якобы, в первую очередь от тестов отказываются, т.е. в пожаре выкидывают огнетушители

у меня есть только один интеграционный тест по позитивному сценарию который а использовал при разработке да ещё я делаю его руками, не выглядит как хороший вариант

ну и ещё интересно, что продуктивной работы в условиях аврала не бывает

не принесут, потому что неопределённость течёт одновременно из требований и из технического решения, наверное я кстати неправильно сформулировал условия, не размытые требования а user story вместо требований, требования это уже моё творчество

ну может его оцифровать и больше не делать такие штуки руками и всё будет хорошо? не медицинское же оборудование судя по юзер-сторям и неформализованным техническим требованиям :)

тут нужно сходить к PO или кто там все закзаывает и объяснить, что при текущей постановке будет выдано решение, которое работает только для одного набора данных. Дальше нужно вместе с PO сидеть и обмусоливать фичу

Если будет говорить про "аврал", то выдавать с одним этим интеграционным тестом. Если требований нет, то и зафиксировать поведение тестами не выйдет

оч хочется имея готовое решение как-то обогатить требования и по требованиям сделать тесты