Автоматизация тестирования
Я тут подумал - если юнит тесты не покрывают все возможные кейсы вашего кода, то они почти бесполезны. Особенно при подходе TDD - сначала тесты, которые покрывают все кейсы поведения и "описывают" его, а потом код. По-моему, это какая-то чушь. Под тесты, описывающие поведение, можно написать множество вариантов кода, которые все будут проходить тесты, но валиться на кейсах кода, которые не описаны тестами. А тесты и не должны описывать все кейсы кода - они первичны и описывают лишь все кейсы поведения. В TDD ничто не запрещает иметь коду дополнительное поведение, не покрываемое тестами. В противном случае, кто или что контролирует, что код не имеет других поведений, кроме описанных тестами?
Ну а если я много прототипирую и меняю код по 20 раз в месяц, даже если немного, то написание тестов к коду - просто бесполезная двойная работа, т.к. у меня и кейсы бизнес-логики, и кейсы кода постоянно меняются. Юнит тесты нормально писать к более-менее устоявшемуся коду, меняющемуся редко - т.к. когда код первичен. И то разумно требовать не 100% покрытия, а лишь основной части.
Итого, TDD - надуманная хрень от извращенцев, перевернувших всё с ног на голову (тесты вперёд того, что они тестируют), а юнит-тесты далеко не панацея даже от простейших программных ошибок в пределах одной функции, не то что ошибок в связи между частями программы.
Каждый раз, когда сажусь писать тесты, в голове стойкое ощущение ненужной дурацкой работы. Особенно, если есть стремление к 100% покрытию.
И то разумно требовать не 100% покрытия, а лишь основной части.
А кто требует 100% покрытия? 
Итого, TDD - надуманная хрень от извращенцев
нужно всего то попробовать или хотя бы понять что это такое.
Ну и тесты хотя бы раз написать, тоже полезно. Я даже когда для себя проекты делаю, часто пишу тесты. Очень удобно, во первых знаешь что данная часть работает как хочется, а во вторых видно когда накосячил.
и меняю код по 20 раз в месяц
В этом случае, что то неправильно или с кодом или с заданием.
Код обычно пишется один раз, может через какое то время его отрефакторить. Может и еще раз, но как раз для этого и нужны тесты.
в голове стойкое ощущение ненужной дурацкой работы
вариантов почему может быть много, неизменно одно - тесты полезная вещь 
И то разумно требовать не 100% покрытия, а лишь основной части.А кто требует 100% покрытия?
Вы прочитайте, что я написал. ТДД описывает тестами желаемое поведение программы, а не кода. Под такое поведение и прохождение всех тестов можно написать много вариантов кода. Но не все варианты выполнения кода будут покрыты такими тестами. Кроме случаев, конечно, когда абсолютно все ветки выполнения программы описаны тестами, учитывая любое поведение кода. Но это малореально.
Ну и тесты хотя бы раз написать, тоже полезно. Я даже когда для себя проекты делаю, часто пишу тесты. Очень удобно, во первых знаешь что данная часть работает как хочется, а во вторых видно когда накосячил.
А надо не часто, а постоянно. Слабо? ))
Я вот тоже щас у себя пишу, но т.к. код постоянно меняется, то смысла в этом особо нет. Пишу лишь там, где более-менее скоро менять не буду.
и меняю код по 20 раз в месяцВ этом случае, что то неправильно или с кодом или с заданием.
Код обычно пишется один раз, может через какое то время его отрефакторить. Может и еще раз, но как раз для этого и нужны тесты.
Вы не разу прототипы не делали, или то, что пока не знаете, как будет выглядеть окончательно? Всегда всё строго в соответствии с планом и по бумажке? А кто план составил и бумажку написал - старшОй? ))
ТДД описывает тестами желаемое поведение программы, а не кода. Под такое поведение и прохождение всех тестов можно написать много вариантов кода. Но не все варианты выполнения кода будут покрыты такими тестами. Кроме случаев, конечно, когда абсолютно все ветки выполнения программы описаны тестами, учитывая любое поведение кода. Но это малореально.
Например, простейшая функция - возвращает результат сложения двух чисел. Как вы опишите хотя бы словами, какие тесты должны быть для этой функции, чтобы покрыть все возможные результаты выполнения кода в этой функции? Т.е. все возвраты и все выбросы исключений.
Например, тесты этой функции должны содержать:
- сложение должно выполняться правильно (кейсы на входные параметры и проверку результатов),
- функция не должна бросать исключения.
Как выполнить второй пункт? Если позволить бросать исключения, то надо перечислять какие и проверять, чтобы они бросались. Но все не перечислишь. Тогда нужно перечислить основные и остальные объединить под общим исключением (типа Exception). Так?
ТДД описывает тестами поведение программы, а не кода
Мне кажется, у вас не совсем верное понимания принципов ТДД.
что пока не знаете, как будет выглядеть окончательно?
на каждом этапе я знаю конечную цель, иначе как тогда вообще что-то писать?
Некоторые части, да могут меняться, но не каждый день. Похоже всё таки дело в коде.
Вот например, я не знаю откуда мне будут поступать данные. Значит для этого пишется "тестовый" сервис, который потом заменится на постоянный.
Но они оба покрываются одинаковыми тестами.
Я тут подумал - если юнит тесты не покрывают все возможные кейсы вашего кода, то они почти бесполезны.
Тесты и не должны покрывать все кейсы кода :) Тесты должны описывать требования к коду.
Под тесты, описывающие поведение, можно написать множество вариантов кода, которые все будут проходить тесты, но валиться на кейсах кода, которые не описаны тестами.
Значть нужно будет проанализировать проблему --> сформулировать новой требование --> написать новые тесты.
В TDD ничто не запрещает иметь коду дополнительное поведение, не покрываемое тестами.
Не запрещает. Так что как ничто не запрещается тебе писать код не обращая внимание на требования :)
Ну а если я много прототипирую и меняю код по 20 раз в месяц, даже если немного, то написание тестов к коду - просто бесполезная двойная работа, т.к. у меня и кейсы бизнес-логики, и кейсы кода постоянно меняются.
Это значит, что у тебя проблемы с проектированием софта. Тест тут не виноваты.
юнит-тесты далеко не панацея даже от простейших программных ошибок в пределах одной функции, не то что ошибок в связи между частями программы.
Никто и не говорит, что тесты - это панацея от чего-либо.
Как вы опишите хотя бы словами, какие тесты должны быть для этой функции, чтобы покрыть все возможные результаты выполнения кода в этой функции? Т.е. все возвраты и все выбросы исключений.
А не нужно все. Достаточно 1-2 регурярных тест-кейса и (если нужно) пара пограничных. Если в процессе жизни окажется, что чего-то не хватает, то всегда можно добавить необходимые тесты.
PS: юнит-тесты - это регриссионное тестирование, т.е. задача юнит-тестов состоит в том, чттобы заявить, что наложенные на компоненту требования исполняются. Ошибки в коде не ищутся юнит-тестами.
А не нужно все. Достаточно 1-2 регурярных тест-кейса и (если нужно) пара пограничных. Если в процессе жизни окажется, что чего-то не хватает, то всегда можно добавить необходимые тесты.
PS: юнит-тесты - это регриссионное тестирование, т.е. задача юнит-тестов состоит в том, чттобы заявить, что наложенные на компоненту требования исполняются. Ошибки в коде не ищутся юнит-тестами.
Ну вот оно так и получается. А как сделать, чтобы все кейсы кода покрыть? Чтобы не было неожиданных выбросов и поведений?
Ну а если я много прототипирую и меняю код по 20 раз в месяц, даже если немного, то написание тестов к коду - просто бесполезная двойная работа, т.к. у меня и кейсы бизнес-логики, и кейсы кода постоянно меняются.Это значит, что у тебя проблемы с проектированием софта. Тест тут не виноваты.
Конечно проблемы. Если я первый раз в теме, и ещё не знаю, как всё работает, а моя идея ещё до конца не оформилась, и я меняю поведение в зависимости от пришедших новых идей, то будет по 20 изменений в месяц.
А как сделать, чтобы все кейсы кода покрыть?
Зачем? Вот добавил тест если значение между 1 и 3, то выбрасывается исключение. Ок 100% покрытие теперь.
Только вот сколько еще искать, а какого фига раз в день, а то и реже выбрасывается это исключение в проге?
и ещё не знаю, как всё работает, а моя идея ещё до конца не оформилась
В этом случае не следует начинать писать код. Нужно выбрать какой-то путь решения, пусть даже не оптимальный и от него уже плясать.
При правильном выборе новые расширения, просто добавляются в существующий код.
Я вижу проблему в том, что вы категорически отказываетесь чему то учится. Мол всё это чушь собачья. Какая нафиг vertical slice архитектура, когда нас и тут неплохо кормят и никакой Гаити нам
не нужен
и ещё не знаю, как всё работает, а моя идея ещё до конца не оформиласьВ этом случае не следует начинать писать код. Нужно выбрать какой-то путь решения, пусть даже не оптимальный и от него уже плясать.
Есть ситуации, когда решение может прийти лишь в процессе, итерационно.
Вы мне тут говорите, что все кейсы тестами покрывать не надо. А сами пока все кейсы не обдумаете, код не начинаете писать. Неконсистенция-с.
При правильном выборе новые расширения, просто добавляются в существующий код.
Какие расширения? Куда? Нет ничего, кода нет, тестов нет. Нечего расширять.
Есть ситуации, когда решение может прийти лишь в процессе
Что то мы опять о разном говорим похоже.
Ну вот простой пример, мне нужна логин форма для приложения, как это будет в итоге делаться не имею никакого понятия.
Решаем, что будем вызывать какое то апи. На входе мейл и пароль, на выходе токен.
Для начала, делаем сервис который просто возвращает токен.
После добавляем в сервис регистрацию в памяти. Затем добавляем вызов стороннего АПИ.
Не понравилось,... хотим регистрацию и логин на стороннем сервисе. Ок, удаляем всё что было и делаем по новому. Но это не значит переписывать по новому почти каждый день. Старый сервис живет какое-то относительно долгое время. Да и он все равно живет отдельно от основного кода.
Хотя в принципе, решение о встроенном логине или внешнем принимается еще до написания кода. Можно даже писать всё и вообще без логина, но перед этим следует узнать как должен будет изменится код при наличии логина.
Есть ситуации, когда решение может прийти лишь в процессеЧто то мы опять о разном говорим похоже.
Ну вот простой пример, мне нужна логин форма для приложения, как это будет в итоге делаться не имею никакого понятия.
Решаем, что будем вызывать какое то апи. На входе мейл и пароль, на выходе токен.
Не надо простых примеров. С логин-формой всё как раз понятно - логин и пароль.
А вот если вы налепите все свои заготовки, а потом придут и скажут, что теперь тут будет не логин и пароль, а 5 разных других параметров. А через неделю - 3 других. А потом опять к логину и паролю вернёмся. Или не вам придут и скажут, а вы сами решите.
Вы просто думаете в привычных для себя терминах, в области, где вы уже наделали сотни логин-форм. А теперь новая область. И у вас выбор - либо учить эту область месяцами, прежде, чем приступить к написанию кода по фен-шую, либо посмотреть по верхам недельку и начать писать сразу же, а в процессе корректировать. Пока это небольшой тренировочный прототип, всё править можно прямо наживую. Тем более, когда результат охота увидеть прям щас, а не спустя месяц штудирования мануалов. Когда появятся устоявшиеся куски, то будут их цементировать юнит-тестами, подробной документацией и прочим.
какие то искаженные представления
ну хотя бы так
https://habr.com/en/companies/ruvds/articles/450316/
Да читал я все эти слащавые статейки чуваков, вчера открывших для себя какую-нибудь модную штуку. ТДД, ДДД и прочая. Гладко было на бумаге, да забыли про овраги.
А уж как подтираются всеми этими пафосными декларациями, когда дедлайн клюёт жареным петухом в задницу... Тут и маститые сеньёры ходят, красные до ушей. А потом и времени нет привести всё в порядок. А потом: - можете показать ваш код? - не могу! )))
PS: юнит-тесты - это регриссионное тестирование, т.е. задача юнит-тестов состоит в том, чттобы заявить, что наложенные на компоненту требования исполняются.
Для регрессионного тестирования не нужно ТДД. Вы сначала можете писать код, а потом тестировать его. А уже потом следить, чтобы он не регрессировал с помощью тестов. А когда делаете прототип, то код идёт вперёд тем более.
Когда в голове возникает мысль, вы её проверяете кодом, а не написанием кучи тестов. Тот, кто не приступает к программированию без тестов, должен быть последовательным, и требовать также полной спецификации, всех юзер сторис, и обязательно широкого ассортимента свежих смузи каждый день. Без этого же нельзя нормально писать код!
А теперь новая область
Не играет особой роли. Всегда есть эксперт(ы) предметной области, вот их и нужно трясти штормом.
Тем более, когда результат охота увидеть прям щас
именно так и делается. И вместо текста - Lorem Impsum
что теперь тут будет не логин и пароль, а 5 разных других параметров. А через неделю - 3 других
ну это уже неправильный подход к разработке.
Хотя тоже бывает, было помню согласованное ТЗ с заказчиком, но заказчиком был шеф, а когда привезли все в цех, работник говорит - а нам так не нужно, нужно по другому. И что всё с нуля переписывать, нет конечно. На месте просто модули соединили по другому.
Но даже если идти как написано, меняется то всего одна страница, все остальное остается как есть.
назад
список