Надоело быть Чаком Норисом ( это отсюда : http://habrahabr.ru/blogs/tdd/116514/ ) , поэтому захотел понять как систематически разрабатывать код и писать к нему тесты.
Не очень понимаю , как на практике можно организовать его ( юнит тестирование ) так таковое. Т е смотрю какое-нибудь видео или читаю мануал и там действительно все понятно , но примеры тривиальные , да и тестирование таких кусочков кода мне кажется не столь важным. Ну т е вероятность совершить ошибку в чем то подобном
| Код |
|
минимальна.
Пытаюсь применить такой подход к своим задачам и встаю в ступор.
Сценарий 1.
Есть WCF сервис.
Соответственно у такого проекта наружу торчит контракт сервиса и контракты данных.
Каждый запрос к такому сервису ведет к обращению к БД считыванию\добавлению\обработки данных и выдачу ( при необходимости) наружу какого то результата.
И как такой паттерн можно протестировать ?
Читал ни раз , что юнит тестирование не должно тестировать обращение к БД. Тогда вообще не понятно , как такой сценарий тестировать.
Или тестировать также как юнит тесты , только это будет называться не юнит тестами , а интеграционными ?
Сейчас попробовал пару методов контракта окружить тестами. Получилось , что я скажем добавляю запись с помощью WCF в БД , а потом напрямую обращаюсь в БД и смотрю добавилась ли эта запись и если добавилась полностью проверяю ее корректность. Так что ли надо делать ?
Что то мне кажется , что я не прав.Причем корректность записей в БД проверяю с помощью тех же классов , коими и добавляю записи внутри WСF сервиса ( сгенерированные LINQ To SQL классы ). Опять же каламбур получается.
Читал про Мок объекты , но опять же не понимаю , чем они тут могут помочь, потому что по сути большая часть работы сервиса - это работа с БД ( LINQ запросы ) и что тут можно проверить эмулируя результаты запросов не понимаю.
Или это просто тот сценарий , где unit тестирование в принципе не надо применять ?
Тогда как правильно тестировать ?
Или вот сценарий 2.
Есть приложение , которое "общается" с этим сервисом.
По сути вся бизнес логика заключается в обращении сначала к сервису , а потом к обращению к сторонним сервисам ( написанных не мной ).
И тут вообще не могу понять как можно наладить автоматическое тестирование.
Во-первых нет даже никаких public методов , чтобы из юнит тестов можно было запускать части программы.
Во-вторых как я могу эмулировать работу этих сторонних ресурсов ? Не писать же мне их эмуляторы. Мне и так порой с ними сложно работать , не говоря уже , чтобы писать генераторы html кода и логику обработки запросов к этим сервисам. Такая эмуляция будет сложнее самой программы , а значит в ней и ошибок будет больше содержаться , чем в программе для которой она эмулируется.
Есть непонятки насчет юнит тестирования так такового. Когда я тестирую какой то код я имею доступ только к public классам и методам.
Тестирование через их вызов безусловно обеспечит покрытие большей части закрытого кода , но далеко не обязательно всего. К примеру я разработал класс и предусмотрел в нем какой то конструктор , но в данный момент этот конструктор нигде не вызывается внутри открытой части кода. Сам класс объявлен как internal и как следствие конструктор я не могу вызвать из тестирующего проекта.
Или надо писать тесты внутри самого проекта ,а потом их вызывать ? Но я про такое нигде не видел\ не читал. Везде тестирующие проекты лежали отдельно в солюшене.
Т е меня с самого начало смутило, что тестирование мы проводим по принципу черного ящика. При этом одной из ключевых характеристик для нас является код ковередж, т е то , что лежит ближе как мне кажется все таки к тестированию с помощью белого ящика.
Тут можно сказать , что не надо писать то , что не используется. Но мне кажется , что если я разрабатываю класс , то я должен предусмотреть все возможные сценарии его использования и предусмотреть соответственно методы для удобной работы с ним. И совсем не обязательно , что сейчас я буду их использовать. Менять же область видимости метода или класса только ради того , чтобы его можно было покрыть тестами мне кажется странным.
Вообще применение юнит тестирование я понять могу в контексте математических задач или задач , где обработка данных идет по большей части внутри программы,а кода отвечающего за взаимодействия с окружением мало. Но у меня как то в проектах как правило наоборот получается...
Ну в общем что то у меня в консерватории не то
. Кто бы мозги мне вправил как надо - было б очень хорошо ЗЫ
Спасибо даже тем , кто просто дочитал до этого места
