TDD *
Разработка через тестирование
Трагедия стопроцентного покрытия кода
Генератор тестовых данных для C++
При unit-тестированиии кода рано или поздно встает вопрос тестовых данных. И если в одном случае достаточно просто несколько жестко зашитых переменных, то в других случаях необходимы сколько-нибудь большие и случайные данные. В управляемом мире нет проблем с генерацией пользовательских типов (взять тот же Autofixture), но мир C++ зачастую вызывает боль и страдание (поправьте меня, если это не так). Не так давно я познакомился с замечательной библиотекой boost::di и под ее влиянием у меня начала созревать идея библиотеки, которая позволила бы C++ программистам генерировать пользовательские типы данных, забитых случайными значаниями, и это не потребовало бы предварительного их описания. Получилось что-то вроде:
struct dummy_member{
float a;
int b;
};
struct dummy{
explicit dummy(dummy_member val, std::string c) : val_(val), c_(c) {}
private:
dummy_member val_;
std::string c_;
};
int main(int argc, char* argv){
auto d = datagen::random<dummy>();
return 0;
}
→ Ссылка на код. Библиотека header-only,C++14. Всех интересующихся прошу под кат.
Continuous Integration UWP приложений в Visual Studio Team Services
С помощью VSTS можно автоматизировать развертывание и тестирование программного обеспечения в различных средах. Суть Continuous Integration заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В частности CI позволяет автоматизировать регрессионное тестирование приложений.
В качестве ознакомления с возможностями VSTS предлагаю опубликовать и настроить Continuous Integration c Unit тестами простого UWP приложения.
Истории
Чистая архитектура в Python: пошаговая демонстрация. Часть 5
REST-слой (часть1)
Git tag: Step12
Наступил завершающий этап нашего приключения в поисках чистой архитектуры. Мы создали модели предметной области, сериализаторы, сценарии и хранилище. Но пока отсутствует интерфейс, который склеивает все вместе: получает параметры вызова от пользователя, инициализирует сценарий с хранилищем, выполняет сценарий, который получает модели предметной области из хранилища, и преобразует их в стандартный формат. Этот слой может быть представлен с помощью множества интерфейсов и технологий. Например, с помощью интерфейса командной строки (CLI): получать параметры с помощью ключей командной строки и возвращать результат в виде текста на консоли. Но та же базовая система может быть использована и для web-страницы, которая получает параметры вызова из набора виджетов, выполняет описанные выше шаги, и разбирает возвращенные данные в формате JSON для отображения результата на той же странице.
Вне зависимости от выбранной технологии, для взаимодействия с пользователем, сбора входных данных и предоставления выходных результатов, нам необходимо взаимодействовать с недавно созданной чистой архитектурой. Поэтому сейчас мы создадим слой для вынесения наружу API для работы с HTTP. Реализовано это будет при помощи сервера, который предоставляет набор HTTP-адресов (конечных точек API), при обращении к которым возвращаются некоторые данные. Такой слой обычно называют REST-слой, потому что, как правило, семантика адресов схожа с рекомендациями REST.
Чистая архитектура в Python: пошаговая демонстрация. Часть 4
Сценарии (часть 3)
Git tag: Step09
Наша реализация ответов и запросов, наконец, завершена. И теперь мы можем реализовать последнюю версию нашего сценария. Сценарий корректно возвращает объект ResponseSuccess
, но до сих пор не проверяет корректность входящего запроса.
Давайте изменим тест в файле tests/use_cases/test_storageroom_list_use_case.py
и добавим ещё 2 теста. Полученный набор тестов (после фикстуры domain_storagerooms
) выглядит следующим образом:
Тестирование с базой данных в .NET
Обычным подходом в .NET к тестированию приложений работающих с базой данных является внедрение зависимостей (Dependency Injection). Предлагается отделить код работающий с базой, от основной логики путем создания абстракции, которую в дальнейшем можно подменить в тестах. Это очень мощный и гибкий подход, который тем не менее имеет некоторые недостатки — увеличение сложности, разделение логики, взрывной рост количества типов. Подробнее в предыдущей статье Что-то не то с тестированием в .NET (Java и т.д.) или в Wiki/Dependency Injection.
Есть более простой подход, широко распространенный в мире динамических языков. Вместо создания абстракции, которую можно контролировать в тестах, этот подход предлагает контролировать саму базу. Тестовый фреймворк предоставляет чистую базу для каждого теста и вы можете создать в ней тестовый сценарий. Это проще и дает больше уверенности в тестах.
Алгоритм Дейкстры и разработка через тестирование
Чистая архитектура в Python: пошаговая демонстрация. Часть 2
Доменные модели
Git tag: Step02
Начнем с простого определения модели
StorageRoom
. Как было сказано ранее, модели в чистой архитектуре очень легкие, по крайней мере, легче, чем их ORM-аналоги в фреймворках.Раз мы следуем методологии TDD, то первое, что мы напишем, это тесты. Создадим файл
tests/domain/test_storageroom.py
и поместим внутри него этот код:Чистая архитектура в Python: пошаговая демонстрация. Часть 1
Год назад мой друг Roberto Ciatti познакомил меня с концепцией, которую Роберт Мартин называет чистой архитектурой. Дядя Боб много говорит об этой концепции на конференциях и пишет о ней очень интересные статьи. «Чистая архитектура» представляет собой способ структурирования системы программного обеспечения, набор соглашений о различных слоях и ролях их участников, нечто большее, чем строгие правила.
Как он уже говорил в своей статье «Чистая архитектура» (перевод на хабре), идея самого подхода не нова, она строится на множестве концепций, которые продвигались многими разработчиками программного обеспечения в течение последних 3-х десяти лет.
Анализ покрытия кода тестами в Ruby
Для начала я приведу небольшой тестовый проект из трёх классов, проанализирую его покрытие с помощью гема SimpleCov, а напоследок немного поразмышляю о том, как анализ покрытия может приносить пользу проекту, и какие есть недостатки у Coverage в Ruby.
Подопытный проект
В качестве проекта для тестирования взята небольшая история о мальчике, который может спрашивать разрешения погулять у матери и у отца.
# Мама очень заботится о своём сыне, и не разрешает ему гулять,
# если он не надел шарф. А ещё она заботится о его успеваемости, поэтому если
# сын не сделал домашнюю работу, гулять ему она тоже не разрешит.
class Mother
def permit_walk?(child)
child.scarf_put_on && child.homework_done
end
end
Hype Driven Development
Команды разработчиков ПО часто принимают решения о программной архитектуре или технологическом стеке, основываясь на ошибочных мнениях из социальных сетей и на всем том, что является скорее модным, чем хорошо изученным, без серьезной оценки возможного влияния на их проекты. Я называю эту тенденцию «Hype Driven Development (HDD)», считаю ее вредной и выступаю за более профессиональный подход. Давайте посмотрим, как обстоят дела, и что мы можем противопоставить.
Новые технологии — новые надежды
Вы встречались с подобным? Команда выбирает новейшие, самые «горячие» технологии для использования в проекте. Кто-то из них читает пост в блоге, тренд в Твиттере или только что пришел с конференции, на которой говорили великие вещи. И вот уже команда использует эту блестящую технологию (или новую парадигму программной архитектуры), но вместо обещанной большой скорости работы и высокого качества продукта, они получают неприятности. Темп работы замедляется, пропадает мотивация, возникают сложности с выпуском рабочей версии. Некоторые команды застревают на этапе устранения багов вместо того, чтобы добавлять новые функции. Им требуется «еще пара дней, чтобы все подчистить».
Ближайшие события
Марсоход, Координаты посадки
В этой серии статей мы строим программное обеспечение марсохода в соответствии со следующими спецификациями. Это позволит применить нам на практике следующие подходы:
- Monolithic Repositories — MonoRepo (Монолитные репозитории)
- Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
- Event Sourcing — ES (События как источник)
- Test Driven Development — TDD (Разработка через тестирование)
Марсоход, Введение
Марсоход, Инициализация
Марсоход, Посадка
Марсоход, Координаты посадки
В предыдущих частях мы создали пакет навигации, а в нем LandRover
класс, который валидирует входные параметры для нашего первого способа использования:
Марсоход должен будет сначала приземлиться в заданном положении. Положение состоит из координат (X
иY
, являющихся целыми числами) и ориентации (строковое значениеnorth
,east
,west
илиsouth
).
Сегодня мы будем рефакторить LandRover
:
Марсоход, Посадка
В этой серии статей мы строим программное обеспечение марсохода в соответствии со следующими спецификациями. Это позволит применить нам на практике следующие подходы:
- Monolithic Repositories — MonoRepo (Монолитные репозитории)
- Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
- Event Sourcing — ES (События как источник)
- Test Driven Development — TDD (Разработка через тестирование)
Марсоход, Введение
Марсоход, Инициализация
Марсоход, Посадка
Марсоход, Координаты посадки
Ранее мы создали пакет навигации, теперь можно приступать к разработке первого варианта использования:
Марсоход должен будет сначала приземлиться в заданном положении. Положение состоит из координат (X
иY
, являющихся целыми числами) и ориентации (строковое значениеnorth
,east
,west
илиsouth
).
Заменяем тестирование алгоритмов тестированием вносимых эффектов
TDD не работает
TDD не работает.
Правда? Странно. У меня всегда работал хорошо.
А вот новое исследование говорит об обратном.
Новое исследование?
Да, глубокое исследование, повторившее шаги другого исследования, проведенного несколько лет назад. Оба показали, что TDD не работает. Новое исследование проходило в нескольких местах, использовало слепой анализ. Выглядит убедительно.
Авторы считают его убедительным?
Авторы рекомендуют проводить новые исследования. Но они скорее всего просто скромничают. Результаты довольно убедительные.
Какие результаты?
Марсоход, Инициализация
В этой серии статей мы строим программное обеспечение марсохода в соответствии со следующими спецификациями. Это позволит применить нам на практике следующие подходы:
- Monolithic Repositories — MonoRepo (Монолитные репозитории)
- Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
- Event Sourcing — ES (События как источник)
- Test Driven Development — TDD (Разработка через тестирование)
Cначала нам нужно инициализировать наш проект.
Марсоход, Введение
Добро пожаловать в серию статьей «Марсоход», где мы будем использовать следующие практики:
- Monolithic Repositories — MonoRepo (Монолитные репозитории)
- Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
- Event Sourcing — ES (События как источник)
- Test Driven Development — TDD (Разработка через тестирование)
В этой вводной статье мы просто обозначим спецификации нашего марсохода.
Примечание. Этот пример является адаптированной для нужд серии статей версией упражнения, представленного на Dallas Hack Club, который сейчас, к сожалению, лежит.
Но сначала, давайте кратко пройдемся по упомянутым выше терминам.
TDD все еще сравнивают с TLD — мнения экспертов
Специалисты из нескольких ВУЗов Европы – Давиде Фуччи, Джузеппе Сканиелло, Симоне Романе, Мартин Шеппэрд, Бойсе Сигвени, Фернандо Уйагуари, Бурак Туран, Наталья Юристо и Марку Ойиво – провели очередное исследование на тему эффективности тестирования ПО. Они рассмотрели методологии Test Driven Development (TDD) и Test Last Development (TLD).
Исследователи сравнивали их по двум показателям – суммарная скорость разработки продукта и качество исходного кода. Первая методология (разработка через тестирование – TDD) вновь не оправдала возложенных надежд: популярная ранее схема тестирования после разработки (TLD) оказалась не менее эффективной. Так что по указанным выше показателям существенных отличий они не обнаружили.
В таком случае чем же объясняется вспышка интереса к TDD, когда она только появилась? Эта методология возникла в 2000-х, так что теперь элемент новизны можно смело сбросить со счетов. Тем не менее, предметом споров она остается до сих пор.
Вклад авторов
asolntsev 303.2tangro 148.0sody 96.0BurundukXP 77.4AlexanderByndyu 69.0Unrul 59.0Tiendil 56.0Igmat 53.0headfire 53.0ETman 52.0