SP
лучше инвестировать в декомпозицию. я так скажу. Профита будет сильно больше и потом с тестами проще.
мне в свое время оч понравилась эта статья:
https://simpleprogrammer.com/back-to-basics-why-unit-testing-is-hard/
Size: a a a
2021 June 11
SP
N
вы уже не раз упоминали декомпозицию, речь идет о классическом ее понимании или здесь что то другое имееться ввиду?
SP
она хорошо объясняет про связь "че мы тестим" и "дизайн системы". Это прекрасно накладывается на другие идеи - dependency elimination principle, Whole Value, functional core imperative shell
SP
information hiding, DRY, SRP, OCP...
VS
Только это самое сложное дело. И факапы тяжело обратимы. "Лучше" говнотестов сотку накинуть
A
Условий там не увидел, assertthat или варианты таких матчеров не считаю за кондишионалы в тестах я скорее говорил о ситуациях где в тесте есть
if some conditional assertthat else asserttrueVS
Ну это уже джунские какие то ошибки, таких не видел не у кого
VS
Тут можно большо сказать про 1 асерт на тест(спорно) и про проверку только 1 аспекта фичи на 1 тест(это очень уже важно)
VS
ну типа if проверяем 1 else проверяем второе.
Такого не видел
Такого не видел
A
Я вот к сожалению видел
A
И более сложные вариации
SP
я имел ввиду штуки как в примере с
hasRange там. Понятное дело что в теле самого тест кейса условий не должно бытьSP
все видели. а еще все видели километровые прекондишены к тестам которые в реальности ничего не проверяют
A
Ну и конечно классика жанра asserttrue(true)
SP
ну в этом и проблема. то где реально надо разбираться и думать люди подменяют на "простые рецепты" аля "не должно быть больше 3-х аргументов и должны быть тесты"
SP
а причем тут coupling, как это все влияет на контракты и обратную совместимость, почему коммиты на 20 файлов измененных для простой фичи - не... слоооожа..
VS
Хз это самое сложное. И в интернетах только самые простые случаи обычно разбираются. Не подкинешь хороших(по твоему мнению) материалов по теме?
VS
А в чём проблема?