Добрый день!

Надоело быть Чаком Норисом ( это отсюда : http://habrahabr.ru/blogs/tdd/116514/ ) , поэтому захотел понять как систематически разрабатывать код и писать к нему тесты.

Не очень понимаю , как на практике можно организовать его ( юнит тестирование ) так таковое. Т е смотрю какое-нибудь видео или читаю мануал и там действительно все понятно , но примеры тривиальные , да и тестирование таких кусочков кода мне кажется не столь важным. Ну т е вероятность совершить ошибку в чем то подобном 


минимальна.

Пытаюсь применить такой подход к своим задачам и встаю в ступор.

Сценарий 1.
Есть WCF сервис.
Соответственно у такого проекта наружу торчит контракт сервиса и контракты данных.
Каждый запрос к такому сервису ведет к обращению к БД считыванию\добавлению\обработки данных и выдачу ( при необходимости) наружу какого то результата.
И как такой паттерн можно протестировать ?
Читал ни раз , что юнит тестирование не должно тестировать обращение к БД. Тогда вообще не понятно , как такой сценарий тестировать.
Или тестировать также как юнит тесты , только это будет называться не юнит тестами , а интеграционными ?

Сейчас попробовал пару методов контракта окружить тестами. Получилось , что я скажем добавляю запись с помощью WCF в БД , а потом напрямую обращаюсь в БД и смотрю добавилась ли эта запись и если добавилась полностью проверяю ее корректность. Так что ли надо делать ?  Что то мне кажется , что я не прав.
Причем корректность записей в БД проверяю с помощью тех же классов , коими и добавляю записи внутри WСF сервиса ( сгенерированные LINQ To SQL классы ). Опять же каламбур получается.

Читал про Мок объекты , но опять же не понимаю , чем они тут могут помочь, потому что по сути большая часть работы сервиса - это работа с БД ( LINQ запросы ) и что тут можно проверить эмулируя результаты запросов не понимаю.
Или это просто тот сценарий , где unit тестирование в принципе не надо применять ? 
Тогда как правильно тестировать ?

Или вот сценарий 2.
Есть приложение , которое "общается" с этим сервисом. 
По сути вся бизнес логика заключается в обращении сначала к сервису , а потом к обращению к сторонним сервисам ( написанных не мной ).
И тут вообще не могу понять как можно наладить автоматическое тестирование.
Во-первых нет даже никаких public методов , чтобы из юнит тестов можно было запускать части программы.
Во-вторых как я могу эмулировать работу этих сторонних ресурсов ? Не писать же мне их эмуляторы. Мне и так порой с ними сложно работать , не говоря уже , чтобы писать генераторы html кода и логику обработки запросов к этим сервисам. Такая эмуляция будет сложнее самой программы , а значит в ней и ошибок будет больше содержаться , чем в программе для которой она эмулируется.


Есть непонятки насчет юнит тестирования так такового. Когда я тестирую какой то код я имею доступ только к public классам и методам.
Тестирование через их вызов безусловно обеспечит покрытие большей части закрытого кода , но далеко не обязательно всего. К примеру я разработал класс и предусмотрел в нем какой то конструктор , но в данный момент этот конструктор нигде не вызывается внутри открытой части кода. Сам класс объявлен как internal и как следствие конструктор я не могу вызвать из тестирующего проекта. 
Или надо писать тесты внутри самого проекта ,а потом их вызывать ? Но я про такое нигде не видел\ не читал. Везде тестирующие проекты лежали отдельно в солюшене.
Т е меня с самого начало смутило, что тестирование мы проводим по принципу черного ящика. При этом одной из ключевых характеристик для нас является код ковередж, т е то , что лежит ближе как мне кажется все таки к тестированию с помощью белого ящика.
Тут можно сказать , что не надо писать то , что не используется. Но мне кажется , что если я разрабатываю класс , то я должен предусмотреть все возможные сценарии его использования и предусмотреть соответственно методы для удобной работы с ним. И совсем не обязательно , что сейчас я буду их использовать.  Менять же область видимости метода или класса только ради того , чтобы его можно было покрыть тестами мне кажется странным.

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

Ну в общем что то у меня в консерватории не то  . Кто бы мозги мне вправил как надо - было б очень хорошо  

ЗЫ
Спасибо даже тем , кто просто дочитал до этого места  


Это сообщение отредактировал(а) nikitao - 16.5.2011, 01:17

из меня фиговый тестер, но порассуждать же тут не запрещается?)
1. что плохого в том, чтобы записать данные в базу, а потом проверить их путем считывания из базы и сравнения? данные совпали - тест пройден)
2. что плохого в тестировании черного ящика, как черного ящика? смысл теста не поломать его, а убедиться, что он проходит набор определенных тестов. не?!



пжлста

Это сообщение отредактировал(а) likegift - 16.5.2011, 07:35

много чего плохого. например, подумайте о производительности таких тестов (для среднего проекта количеством юнит-тестов в несколько тысяч). кроме того, после первого теста, который изменит данные не в моке, а в реальной базе, как их там восстанавливать для следующего теста? в третьих, использование базы - уже не юнит-тестирование, а интеграционное.

а чо их восстанавливать? это же тестовая база - drop table/create table 
а если серьезно, то мне самому любопытно какая методика будет правильная.

Да не. Ничо плохого нет. Просто получается, что от момента попадания бага в код до момента его обнаружения может пройти много времени, что тоже с виду не очень хорошо. Хотя мне кажется , что это скорее теоретическая , чем практическая проблема.