?

if a:
   if b:
       print(b)
   else:
       print(not b)

Так что да, по веткам все верно

в ваших кейсах:

А б
А не б
Не а б
Не а не б

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

так про то и говорят

насколько я понял, автор утверждает что все 4 кейса важны:

> мы полчаса сражались, чтобы было 4 теста вместо трех,

с точки зрения черного ящика, если учитывать, что реализация может поменяться

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

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

так про то и разговор был, что тестировщики и разработчики придумывают разные кейсы из-за разных подходов

> Вопрос скорее был даже не в том, что там обязательно должно было быть 4 теста, а в том, что разраб вообще сооовсем не понимал, как их может быть 4, тут же все очевидно!

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

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

> не сильно затратно проверить полным перебором))
полным перебором всех вариантов на свете?) опять же зачем, если достаточно 3)

> кейс в принципе не пришел в голову

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

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

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

не погладил с командой и его попросили перейти в куа - самое эпичное во всей стори 😂

Хах, есть такое))

А б
А не б
Не а б
Не а не б

Разработчики иногда думают что не ломали, а на самом деле сломали.

Или думают что всё делали правильно, а при мерже пропустили строчку. Что привело к потрясающему багу из-за эффекта пропущенной строчки на логику сервера.  Как я решил посмотреть в логи, то очень сильно удивился, мягко выражаясь -- там одно действие вызвало больше десяти тысяч строчек лога о_О

Кроме того, помимо statement & branch & decision coverage может быть ещё и state coverage, и в плане state заводить на перебор всех состояний А и Б вполне валидно.

Плюс! Лайк! Подписка под каждым словом)))