Ну вот и у меня теперь есть канальчик

Для демонстрации уровня публикуемого контента необходимо добавить это!

Комменты включены, жизнь налаживается!

Полтора года назад организованной группой лиц по предварительному сговору и под моим техническим руководством начали пилить Систему. Система представляет собой полсотни самостоятельных сайтов на Drupal с богатейшими редакторскими возможностями по созданию контента, но главное - с общим контентным и редакторским пространством на все сайты. Редактор создает контент и выбирает - на какие сайты он автоматически отправится, и какие его части будут автоматически переопределены по дороге (ну там, телефон другой, фоточка, ссылочки). И дальше оно само.
В общем, сегодня из этой группы сайтов первые семь увидели жизнь в продакшне. Об этом я с радостью бы рассказывал часами, однако NDA-шмендиэй, больше ничего сказать не могу. Но все равно - ура!

Когда-то немножко писал про TDD в целом. По-прежнему считаю методику очень годной. Особенно когда каждый раз начинаешь плясать от Feature/Integration test, а не от Unit test (что было бы все-таки уныло). Поэтому постоянно, когда есть возможность, её применяю.

Помимо прочего, со временем становится очевидным еще одно важное свойство TDD. А именно — методика позволяет тебе, так сказать, ехать в полосе, видеть свет в конце тоннеля, и в то же время не дает разгуляться безудержной фантазии там, где это противопоказано.

Например. Делаем мы, скажем, набор классов с наследованием, понадобится фабрика, дерево подклассов, перегруженные функции, инъекции зависимостей и все такое. Наиболее правильным (и с точки зрения TDD тоже) представляется есть этого слона по кусочкам:

1. Сделать первый подкласс, добиться чтобы он выполнял свою функцию (сразу после написания теста на этот подкласс, разумеется).
2. Сделать второй подкласс, добиться чтобы и он работал.
3. Посмотреть, что между ними общего, провести рефакторинг, вынести общие места в базовый класс, или создать еще один слой абстракции.
4. Убедиться что после рефакторинга всё по-прежнему работает.
5. Повторить с пункта 2.
6. Когда задача 1–5 решена, провести еще один рефакторинг, добавить инъекции зависимостей, дописать интерфейсы к конкретным сервисам и т.п.

Однако неуемное воображение постоянно заставляет разработчика, еще не доделав 1, сразу переходить к 3. Потому что мозг видит потенциально общий метод в подклассе и немедленно говорит: — так, это мне нужно будет еще в тех трех классах, но нужно будет учесть еще два нюанса, щас мы с тобой такую абстракцию забабахаем!

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

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

Вот чтобы этого не было, помогает обозначенный эффект TDD: консолька как бы говорит — пока у тебя красные тесты, пиши то что тесты говорят! А помечтаешь когда всё исправишь.

Кстати, курс https://course.testdrivenlaravel.com/ очень рекомендую для всех кто пользуется Ларавелом. Это не только прекрасный курс по TDD, это еще и единственный видеокурс, который я с удовольствием изучил до конца, притом что ненавижу видеокурсы в частности и вообще видеоматериалы по программированию.

Да, материал за последнее время изрядно подорожал. Но ведь и Адам на свежем фото тоже прилично схуднул!