Наброшу немного.

как проще объяснить людям почему "если ты делаешь стаб то тебе надо определить поведение всех методов в соответствии с контрактом" это важно?

Ну то есть, люди не понимают почему если на вход подается коллекция с методами count и isEmpty, и реализация использует скажем if($collection->count() === 0) то "нафига нам стабить isEmpty`?

От части я могу объяснить это тем что люди привыкли к интерфейсам на 10 методов и заебешься все стабить и описывать.

Всё той же хрупкостью тестов? Мол "я в гробу видал фиксить стабы везде, если вдруг в реализации начнём юзать isEmpty."
Ну и да, если метода 3, а определяют только один, потому что "ну в реализации же только он", то только хрупкость и в целом завязка на детали реализации вместо тестирования сугубо поведения. А если их 10, то тут большинству будет впадлу закрывать всё.

тут две проблемы:

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

Ну, я ленью обычно убеждаю.
Хрупко - надо часто переписывать и чинить - лень, значит надо не хрупко.
Интерфейсы с тонной методов надо стабать целиком, иначе хрупко и см. пункт первый. А стабать 10 методов лень, значит надо мельче.

ну вот пока не выходит)) у людей как-то размыто представление границы интерфейса (что тест он как бы с одной стороны а реализация с другой)

Зачастую только на примерах получается что-то показать. Мол "вот смотрите нормальный код менялся стопицот раз за месяц, а тест нет, клево же". И все такие кивают и соглашаются.

(и всё равно продолжают как раньше, но меньше)

Нуди про блекбоксы, пока людей это слово триггерить на ревью не начнёт

Вообще это ж проблема не только в тестах. Люди очень зацикливаются на данных и имелементации, вместо контрактов и поведения. Что делать - хз.

Болит везде, и в тестах и в проектировании в целом, что потом часто зудит в рефакторинге и даже в банальном пользовании чужим кодом.

Хотя казалось бы, профит на поверхности, вам дают способ меньше думать "в долгую".

Возникла небольшая идейка и в качества эксперемента хочу предложить кому скучно попробовать предложить свой вариант решения простой задачки.

Вот условия: https://gist.github.com/fesor/bdb1e18ca8778e82faa1245f318eab81

Варианты в любом виде можно даже в виде пары предложений общей сути решения скидывайте в личку. Очень интересно глянуть какие варианты получатся.

По итогу запилю разбор решений с оценкой плюсов минусов как тестить.

Уточнение: какие статусы могут быть у проекта? Open/closed? Или как понять действие "завершить проект"?

Introduce <<Deprecated>> attribute by beberlei · Pull Request #11 · beberlei/php-src
https://github.com/beberlei/php-src/pull/11

Bitcoin, Ethereum, Blockchain - триггеры спама)

А теперь ещё и Тесла с Маском)

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

если они не нужны в имплементации, зачем имплементация требует более жирный интерфейс, чем ей нужен?

туше,

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

теперь переходим к дата-провйдеру и вопрос -- в каком виде строить возвращаемые значения второго метода? Ну я могу только предположить, что $this->never() выставить...

но, кажется, попахивает лишней работы ради философии