Мысль уловил. Интеграционные тесты покрывают сразу большой кусок функционала. Отрефакторили внутри хоть что-то — тест может лечь. Ну, именно этого именно в данном проекте я не боюсь :)) Спасибо!
Хватит болтать, начну пробовать и есть слона (по кусочкам) :)
Да просто настал момент, проект получил новое развитие и очень страшно вносить изменения. Даже руками протестировать всё — непросто. Вот и ищу, с какой стороны подобраться, не отрицая возможности, что и правда пытаюсь съесть слона целиком.
В принципе, соглашусь. Скорее всего я на самом деле не о TDD должен говорить, а о наличии интеграционных тестов. Принятие подобного факта снимает часть вопросов, и это уже что-то :-)
Да, проект уже есть, причём это жёсткое legacy, но сейчас пошла волна изменений.
Мне ваша идея нравится, сам думал в эту же сторону. Просто действительно, код явной логики не содержит, в основном это разнообразные взгляды на данные в БД (5Гб). И меня вводит в ступор логичное предложение «написать обманку». Совершенно не представляю, как!
Я уже ответил ниже. Проект — legacy. Там нет репозиториев. Там DataTable и хранимки. И довольно обширная модель данных, которую тяжело просто так взять и описать для тестов :-( Поэтому я не знаю, с какой стороны подступиться. То ли рефакторить до внятной доменной модели, чтобы совсем не использовать БД в тестах, то ли взять тестовую БД с левыми данными, то ли взять себя в руки и написать стопку генераторов этих самых тестовых данных…
Взял в руки эту книгу, нашёл главу (6, про сопутствующие инструменты: NInject, Moq). Оно? В этой главе не было ничего толкового. Создаём фейковый репозиторий, задаём ему необходимое поведение и прогоняем в тесте.
Вы можете помочь с примерами? Теорию я осознал, да. Но руки не делают (ц).
Допустим, страница с просмотром расходов пользователя: из параметров берётся user_id, дёргается хранимка, возвращающая сумму расходов по периодам, всё это отображается на страничке в таблице. И то же самое для всех подчинённых данного сотрудника, если они есть. Потенциальных мест для ошибок — немало. Но как создать для этого случая тесты?
голосую за JSON: опыт подсказывает что в первое время, для отладки будет необходимо руками набивать все эти сообщения; в XML это делать ооочень быстро надоедает!
вот в своем последнем проекте я стал пользоваться s-exp'ами — вышло довольно удобно: (volume (id 1) (size 5))
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Хватит болтать, начну пробовать и есть слона (по кусочкам) :)