Для создания mock-объектов я использовать библиотеку Moq code.google.com/p/moq
Она дает не создавать stub-объекты (class StupProductRepository: IProductRepository), а оборачивать их new Mock(). Это удобно тем, что нет лишнего кода для создания stub-объектов и возможно задавать поведение mockRepository.Setup(r => r.GetLastProduct()).Returns(new Product())
Как разруливать ситуацию когда в разных местах должна ижектитится разная реализация интерфейса IProduct?
Большое кол-во тестов действительно может стать массой, которую сложно поддерживать. Для написания хороших тестов, которые помогают, а не отягощают, надо набить руку и… шишки.
Да, на моделе данных, но без их выборки из базы данных. От этого будет зависить эффективность теста. Более подробно я написал здесь blog.byndyu.ru/2009/04/blog-post.html
Я согласен, что надо тестировать также и с взаимодействием с базой данных, но это уже интеграционные тесты.
В данному случае под «доменом» я понимаю домен из Domain Driven Development. Тут более уместен вопрос «какие преимущества дает DDD?». Краткого ответа нет, но думаю ссылку на ответ я тебе подкинул ;)
Вся идея TDD базируется на том, что проектирование кода идет в тесте. Если я буду рисовать UML диаграммы, то это абсолютно ничего не даст. Нет смысла рассуждать о сущностях в квадратиках, когда можно просто написать тест с их участием и посмотреть как они себя ведут сразу в коде.
Я понял ваши опасения. Дело в том, что это не функцию API приложения, а название теста. Название теста должно говорить о том, что в этом тесте происходит. Я даже больше могу вам сказать, очень популярна подобная запись:
send_special_report_to_administrator_if_no_reports_created
Если я буду создавать БОЛЬШОЕ приложение, то на это уйдет гораздо больше 40 минут :) Я могу вам посоветовать следить за развитием крупных проектов с открытым исходным кодом. Сейчас таких очень много. В нашей команде большой популярностью пользуется NHibernate.
Я могу поделиться нашим опытом. Оба текущих проекта — это веб-сайты. Тестируем с помощью Selenium. Тесты также написаны на xUnit. Тесты GUI запускаются каждую ночь при сборке релиза с помощью TeamCity.
Мда, даже не знаю как еще сказать. Может кто поможет? :)
Просто пару наводящих вопросов. Когда рефакторите вы добавляете или удаляете функциональность? Проходят ли тесты после рефакторинга? И наконец, участвует ли код приватного метода при проходе теста?
Если мы пишем сначала тест, а потом добавляем код, который делает этот тест рабочим (зеленым), то не может появится кода (никакого, даже приватного внутри класса) без теста на него.
Другими словами, откуда берутся приватные методы? Сначала ведь их нет, как например в моем примере. Но вот если мы возьмем и вынесем условие reports.Count == 0 в приватный метод IsReportListEmpty()? Функциональность системы не измениться, при этом все тесты буду проходить, как и до создания метода IsReportListEmpty. При этом приватный метод будет протестирован.
Это моя главная цель. Рад, что на пользу.
Она дает не создавать stub-объекты (class StupProductRepository: IProductRepository), а оборачивать их new Mock(). Это удобно тем, что нет лишнего кода для создания stub-объектов и возможно задавать поведение mockRepository.Setup(r => r.GetLastProduct()).Returns(new Product())
Для этого практически во всех IoC-контейнерах предусмотрена условная логика. Например, для Ninject wiki.github.com/enkari/ninject/conventions-based-binding
На счет того, чтобы тесты не пришлось перелопачивать есть хорошая книга www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054
Большое кол-во тестов действительно может стать массой, которую сложно поддерживать. Для написания хороших тестов, которые помогают, а не отягощают, надо набить руку и… шишки.
Я согласен, что надо тестировать также и с взаимодействием с базой данных, но это уже интеграционные тесты.
Вот здесь довольно известный пример www.objectmentor.com/resources/articles/xpepisode.htm
send_special_report_to_administrator_if_no_reports_created
Просто пару наводящих вопросов. Когда рефакторите вы добавляете или удаляете функциональность? Проходят ли тесты после рефакторинга? И наконец, участвует ли код приватного метода при проходе теста?
Другими словами, откуда берутся приватные методы? Сначала ведь их нет, как например в моем примере. Но вот если мы возьмем и вынесем условие reports.Count == 0 в приватный метод IsReportListEmpty()? Функциональность системы не измениться, при этом все тесты буду проходить, как и до создания метода IsReportListEmpty. При этом приватный метод будет протестирован.