Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Но самым важным здесь является создание наброска будущей архитектуры. Просто делается это не на доске для рисования (что имеет свои преимущества), а прямо в коде.
И вот я перелопачиваю гору кода при каждом чихе,
В такой ситуации рефакторинг дело очень частое. И вот я перелопачиваю гору кода при каждом чихе, а вместе с этой горой переписываю тесты.
но я не всегда могу похвастаться хорошей продуманной архитектурой, правильным выделением классов и прочими best practicies.
Спасибо за прекрасную коллекцию заблуждений.
Выделяется отдельный класс с соответствующим методом и контрактом, вынесеным в отдельный интерфейс, который будет пробрасываться через прокси-класс, причем сам этот класс имплементирующий интерфейс будет инстанцироваться специальной фабрикой с конфигурирацией вынесеной в отдельный xml, который генерируется…
assertEqual(666, sum(123, 543));
, реализация — одна строчка типа return a+b;
. Зачем все эти ваши контракты и фабрики? Это если вообще нужно выделять сложение в функцию/метод.То, что вы назвали “ООП головного мозга” – это описание работы самого обычного DI, верного и незаменимого друга TDD-шника.
Т.е. в теории оно как бы надо, а на практике я никогда не видел пользы от избавления от зависимостей типа System.DateTime.Now, например.
2. изменения кода влекут переписывание многих (а то и всех) тестов.
3. мнообразие тестов (скажем, форма из N полей, сводится к 2^N тестам), 3\4 из которых очевидна (как только начинаешь писать тест, уже видишь, код содержит баг или нет).
4. тесты на специфичные баги: нашли баг, добавили тест, исправили, тест проходит, отлично; но погодите, а в других местах нет ли этого же бага?
5. трудно придумывать нужные тесты: чаще, при разработке, мы даже не задумываемся, что возможны такие условия, при которых система может упасть
6. сложность эмуляции окружения сложного (а особенно сильносвязанного) приложения: нужно создать mock-БД, наполнить верными и заведомо неверными данными, поднять фреймворк или эмулировать его часть
6. многообразие типов тестов: не юнит-тестами едиными, нужны и интеграционные тесты, и автоматизированные тесты…
7. тесты не улавливают магические ошибки, которые связаны с бубном и фазами луны: нужна реальная ситуация с реальными данными, чтобы хотя бы догадаться, как составить тест, а уж чтобы он (не)проходил…
8. концепция TDD требует тщательного проектирования: если мы тесты пишем до написания кода, а детали реализации не видны до рабочего прототипа, то у нас проблемы.
assert(4, sum(2,2));
), хардкодим реализацию (sum (a, b) { return 4; }
) и забиваем, пока приложение не выстроится из таких кусков.Нужно создать стаб-объект, эмулирующий БД. Зачем нам настоящая? Баги в БД ловим? И т. д.
$obj->createSomething($data);
, который создает что-то из полученных данных. Пусть он создает запись в БД. Если я внедряю фейковую базу, что я протестировал? Ну вернул он true
, как и требовалось, но на реальных данных валится.Ну вернул он true, как и требовалось, но на реальных данных валится.
Ну вернул он true, как и требовалось, но на реальных данных валится.
Разработка через тестирование (англ. test-driven development, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. (wiki)Дело в том, что через тесты описывается архитектура приложения, а потом реализуется в коде… Хорошо написанные тесты заменяют собой документацию по архитектуре приложения.
нужны по возможности чёткие спецификации, потом хорошая модульная архитектура, затем слабо связанный дизайн
Т.е. хороший инструмент, если в подчинении оказалась орда code monkeys.
Это смотря какого теста
В этом случае ТДД — это зеркало спецификации.
Почему изучать TDD трудно и что с этим делать. Часть 1