Первый раз достаточно близко я познакомился с тестированием лет 5-6 назад, как раз начало моей карьеры. Тогда, я помню, мне рассказывали про покрытие кода тестами. Причем никаких Unit тестов меня не просили писать, просто говорили: “вот видишь if с тремя условиями, который ты написал, ты должен проверить все эти три условия”. Подразумевалось, что я, после того как напишу код, должен его проанализировать, и полностью протестировать обычным проходом по интерфейсу приложения. Как вам? Со временем знания в тестировании у меня немного выросли, я немного научился писать тесты. Я до сих пор не видел и не участвовал ни в одном живом проекте, написанным при помощи Test Driven Development (TDD) подхода. Основа моих знаний была в подглядывании того, как делают это коллеги в предыдущей моей конторе, чтении статей (например, у Алесандра Бындю была отличная статья “TDD для начинающих. Ответы на популярные вопросы”), просмотра пару сринкастов. Я решил покончить с безграмотностью и проникнуться темой, для этого я сел за прочтение книги The art of Unit Testing with Examples in .NET. Притом, что в текущей конторе? можно сказать, что тесты пишу только я для своего кода. Нужно быть образцом.

Для логгирования приложений, написанных под .NET большинство разработчиков используют log4net (а другие разработчики используют log4 под другие платформы). Но так, к сожалению, бывает не везде. Так, например, в нашем проекте до сегодняшнего дня мы использовали свою самописную библиотеку для логгирования. Была она, видимо, написана давно нашим team leader, но так как нас сейчас покидает текущий team leader, мы решили так же распрощаться с некоторым legacy кодом, который был дорог нашему лидеру, но который не особо то мы хотим поддерживать. Сразу уточню, что код написан отлично, и наш team leader – отличный кодер, но log4net имеет больше преимуществ, а текущий логгер нам приходится частенько дописывать функционалом, который уже давно есть в log4net.

Так получилось, что на текущей работе мне пришлось настраивать CCNet build сервер для создания среды непрерывной интеграции. Что это такое и зачем нужно можно почерпнуть из многих источников, из которых можно выделить статью Мартина Фаулера [1], а так же книгу Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска [2], о которой Мартин Фаулер так же хорошо отзывался. Про эту книгу я могу сказать одно, она мне попалась в переведенном варианте пару лет назад (или даже больше), и переведенный вариант был ну просто ужасен, после которого я посчитал, что нужно бы начинать читать книги только на оригинале (если оригинал - английский язык, что бывает в большинстве случаев).

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

Признаюсь, я фанат регулярных выражений. Всегда, когда я вижу задачу, которую можно решить при помощи RegEx, я загораюсь и бегу писать тест под новенькое Regex условие. Раньше даже специально держал установленный SharpDeveloper, так как там была удобная тулза для проверки RegEx выражений, сейчас же я немного поумнел и для каждого RegEx пишу просто отдельный тест и в нем же и тестирую. Вообще, нужно стараться находить те задачи, которые предназначены для решения их через регулярные выражения. Мне сложно помнить синтаксис регулярных выражений, точнее приходится их писать не так уж и часто, потому из головы постоянно вылетает: какой символ отвечает за начало строки и т.п. Для освежения я постоянно пользуюсь очень легкой статьей Регулярные выражения на RSDN.

В данной статья я бы хотел рассказать, в чем различие данных паттернов. Начнем с первого главного – Model-View-Controller – это фундаментальный паттерн, который нашел применение во многих технологиях, дал развитие новым технологиям и каждый день облегчает жизнь программистам. Если вы начнете спрашивать архитекторов о том, как реализовать данный паттерн, то, я думаю, вы сможете услышать несколько разных ответов и соответственно несколько разных решений. Вообще, объединяет все эти паттерны – выделение User Interface (UI) от логики программирования, что позволяет дизайнерам делать свою работу, не задумываясь о коде программы. Если вспомнить школьное и студенческое программирование, то всплывает картина огромного количества строчек, написанных в code behind интерфейсов, что не является хорошей практикой. Так же есть предоставляется возможность выделения модели данных, что дает разработчикам возможность создания модульных тестов над ними.