Книга The art of Unit Testing with Examples in .NET
- modified:
- reading: 5 minutes
Первый раз достаточно близко я познакомился с тестированием лет 5-6 назад, как раз начало моей карьеры. Тогда, я помню, мне рассказывали про покрытие кода тестами. Причем никаких Unit тестов меня не просили писать, просто говорили: “вот видишь if с тремя условиями, который ты написал, ты должен проверить все эти три условия”. Подразумевалось, что я, после того как напишу код, должен его проанализировать, и полностью протестировать обычным проходом по интерфейсу приложения. Как вам? Со временем знания в тестировании у меня немного выросли, я немного научился писать тесты. Я до сих пор не видел и не участвовал ни в одном живом проекте, написанным при помощи Test Driven Development (TDD) подхода. Основа моих знаний была в подглядывании того, как делают это коллеги в предыдущей моей конторе, чтении статей (например, у Алесандра Бындю была отличная статья “TDD для начинающих. Ответы на популярные вопросы”), просмотра пару сринкастов. Я решил покончить с безграмотностью и проникнуться темой, для этого я сел за прочтение книги The art of Unit Testing with Examples in .NET. Притом, что в текущей конторе? можно сказать, что тесты пишу только я для своего кода. Нужно быть образцом.
Эта книга написана уже, примерно, полтора года назад. Выбрал я ее не случайно, ее рекомендуют даже php программисты, хоть большинство примеров у нее написаны на языке C#. А так как я видел достаточно разных рекомендаций для прочтения именно этой книги, я и решил начать с нее, чтобы покончить с безграмотностью.
Автор этой книги Roy Osherove достаточно известный блоггер, так же он ведет мастер-классы по TDD, бывает работает консультантом для контор, которые хотят применить TDD у себя в проектах (и об этом он не раз пишет в этой книге, приводя удачные и не удачные примеры внедрения методологии). Работает главным архитектором в компании Typemock, которая выпускает платные инструменты для более удобного написания тестов и анализа кода.
Книга, в принципе, будет полезна разработчикам любых платформ и языков. В примерах большего всего используется C#, как подопытный язык (есть немного кода на Java), NUnit как фреймворк для написания Unit тестов, и Rhino Mocks фреймворк для использования Mock и Stub объектов в Unit тестах (кстати, раньше не знал, что это разные вещи, знал только Mock объекты). Для остальных платформ и языков можно будет использовать, наверное, только теорию, которой в книге предостаточно. Либо если есть похожие фремворки для вашей платформы, то вы сами сможете ознакомиться с ними и перевести код примеров на них. По крайней мере, я знаком только с Moq фреймворком, но понять синтаксис Rhino Mocks для меня не составило трудностей.
Итак, о чем же сама книга? Как всегда на официальном сайте книги есть возможность скачать пару глав, чтобы начать знакомиться с книгой: для того чтобы оценить подходит она вам или нет. На сколько я знаю, ее не переводили на русский язык, а так как времени прошло достаточно с момента выхода, то, скорее всего, и не переведут. Начинается книга, как и любая другая с глав “Hello world!”, о том, что нужно, чтобы писать тесты, какие инструменты, ну и пишется первый тест. Дальше достаточно бегло описываются фреймворки, которые автор будет использовать в примерах: NUnit и Rhino Mocks. Упор на Rhino Mocks, на сколько я понял, автор сделал потому, что в его блоге он собрал когда-то статистику, что этот фреймворк используют больше остальных. Мне кажется, что ситуация сейчас поменялась, и более популярный фремворк все-таки сейчас - это Moq. Ну а NUnit остается все таким же популярным фреймворком для тестирования. Одно время я переходил на MbUnit, потому что там было больше возможностей, но NUnit на данный момент хорошо подтянулся и догнал конкурента.
Чем дальше, тем книга становится все более интереснее. Достаточно подробно описываются принципы написания тестов, как их нужно оформлять, и главное – это то, что приводятся антипаттерны, которые я сразу узнал в своем коде (нужно совершенствоваться, теперь знаю куда).
Так же я получил ответ на свой давний вопрос. Когда-то я написал статью Тестирование NHibernate приложений на примере MbUnit, и тогда я получил один из комментариев:
У меня вот вопрос. А зачем? Зачем тестировать ORM? Собсно весь кусок взаимодействия с ORM выносится в отдельный класс(отдельные классы), и используется какой-нибудь IoC-контейнер.
Что конкретно вы тестируете в ORM то? Маппинги? Запросы?
Там у меня был немного специфический случай, потому я выкрутился красиво, что, вроде, нужно было. Хотя я не понял, а почему нет: это мой интеграционный тест, я проверяю, что структура базы соответствуют маппингам, маппинг соответствует классам, если использую специальные запросы, то тестирую и их. Не раз спасало. В общем, я не знал, что ответить. В книге я получил ответ на свой вопрос – это полезно и нужно, автор тоже тестирует слой доступа к данным, и приводит аргументы зачем это.
Помимо того, как правильно писать тесты, в книге найдете информацию о том, как внедрить TDD практику у себя в конторе, как сделать написание тестов более эффективнее, как работать с Legacy кодом (а это считай очень важно, когда вводишь TDD для существующего проекта). И основное – это ответы на самые распространенные вопросы, на которые нужно отвечать, когда ты становишься тем человеком, который решил внедрить TDD в команде (вопросы связанные с временем, деньгами, знаниями и остальным). Я пытался как-то объяснить своим новым коллегам это, мне покивали, но доводы были не сильными.
Так же в книге есть обзор большого количества фремворков, которые могут пригодиться для тестирования. Среди которых, понятное дело, есть и платные фреймворки, написанные компанией Typemock, где работает автор.
Рекомендую книгу всем конторам, которые практикуют TDD у себя, и которые просто пишут тесты к своему коду (это мой случай), да в общем всем конторам. И моя рекомендация к лидам и менеджерам, не говорите “Пишите тесты”, а прочитайте книгу сами, либо попросите сотрудников, потом проведите тренинги, и все изменится. Мне кажется – это очень важная часть разработки. Я написал уже много тестов, но после прочтения книги понял, что их можно было написать намного более правильно и понятнее. Книга содержит отличные рекомендации. Не могу сказать, что она содержит ответы на все вопросы, и не могу сказать, что согласен с книгой во всех деталях, но то, что книгу стоило прочесть – это точно.