Если у вас мало опыта в написании тестов, проще всего начать с модели предметной области (или более высокого уровня чуть ниже пользовательского интерфейса).Когда вы разработали модель модели домена с помощью TDD, вы будете знать, какой должна быть схема базы данных.Возможно, было бы хорошо отложить введение базы данных в систему, потому что работа с миграцией схемы базы данных добавит некоторые издержки к разработке.И это также приведет к лучшему дизайну, потому что тогда модель предметной области будет лучше отделена от уровня базы данных.
Если вы разбираетесь в написании тестов и в TDD, может быть полезно начать с конца- сквозное тестирование (в этом случае они будут написаны для веб-интерфейса) и создание тонкого фрагмента функциональности, который затрагивает все архитектурные части системы (как рекомендуется в GOOS ).Другими словами, создайте ходячий скелет .Преимущества этого подхода состоят в том, что (1) вы сможете решать и решать проблемы интеграции с самого начала, (2) когда сквозные тесты используются для управления проектом, это может помочь вам избежать реализациилишние детали и (3) трудности написания сквозных тестов требуют от вас улучшения архитектуры и добавления контрольных хуков, которые также могут быть полезны при мониторинге системы в работе.(Целенаправленное модульное тестирование все еще будет необходимо, потому что они обеспечивают проектное давление на уровне класса, плюс они работают быстрее и, следовательно, обеспечивают более быструю обратную связь.)для интегрируемости .