Fixie – тестирование по соглашению

01Некоторое время назад попался мне твит о том, что знакомый стал использовать новый тестовый опенсорсный фреймворк Fixie и очень этим доволен. Так, что даже решил исправить все тесты в своем проекте на новый движок. После такого, я просто не мог оставаться в стороне и даже не взглянуть, что это за зверь такой и чем он так радует окружающих.

Далее я хочу представить вам обзор фреймворка, его возможности, и понять, действительно ли это новое слово в тестировании, стоит к этому присмотреться или же можно пройти мимо и забыть.

Как сказано на самом сайте, Fixie – Conventional Testing for .NET. Т.е. тестирование по соглашению. Под соглашениями здесь понимается то, к чему мы в целом привыкли – все операции выполняются на основе «устного» договора, джентельменского соглашения об именовании. Ближайший пример – scaffolding. Это когда мы договорились, например, что тестовые классы содержат слово Test, или что тестовые классы должны быть публичными и ничего не возвращать.  Тогда такие классы будут распознаны как тестовые. И больше никаких атрибутов и всего такого прочего. Просто классы и методы.

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

Установка и первый тест

По умолчанию, Fixie настроен так, что тестовыми классами является всё, что оканчивается на Tests. Тестовыми методами – всё что внутри этих классов и не возвращает значения. Т.е. теоретически и, на самом деле практически, вот такой код уже будет распознаваться как тест:

Подробнее

Покрытие кода

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

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

Значение покрытия не дает ничего. НИЧЕГО.

Предлагаю рассмотреть несколько сценариев, когда покрытие кода не дает желаемого результата.

Подробнее

Mighty Moose Risk Analysis

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

 

Hard’n’Heavy!

Обзор работы с Mighty Moose

Обычный цикл разработки с помощью ТDD подразумевает использование подхода Red-Green-Refactor, который конечно же работает хорошо и при одного теста и знании горячих клавиш достаточно производителен. Однако, если затрагивается сложный функционал, то при рефакторинге кода могу затрагиваться самые разные тесты и тогда приходится вручную запускать все тесты, дабы убедится что ничто не сломано и все работает как планировалось. Вот это действие уже накладное и может вызывать большие потери времени разработчиков при запуске всех тестов и ожидании результатов, даже если предположить, что все тесты написаны качественно и проходят очень быстро.

В этой ситуации на помощь приходит Mighty Moose с подходом continuous testing (непрерывное тестирование). Мне логичным появление такой системы, с учетом того, что до этого набрали популярность и оправдали свое существование техники непрерывной интеграции и непрерывной доставки. Mighty Moose действительно оправдывает инсталляцию и занимаемую оперативную память.

В видео подкатом я в обзорном режиме показываю как работать с Mighty Moose.

 

Hard’n’Heavy!

 

 

Непрерывное тестирование с Mighty Moose

Уже очень давно не утихают разговоры про Test Driven Delepoment и большинство разработчиков скорее всего уже на собственном опыте ощутили насколько безопасным и приятным становится разработка и рефакторинг приложений, когда существуют тесты. Полный набор тестов.

Обычный цикл разработки с помощью ТDD подразумевает использование подхода Red-Green-Refactor, который конечно же работает хорошо и при одного теста и знании горячих клавиш достаточно производителен. Однако, если затрагивается сложный функционал, то при рефакторинге кода могу затрагиваться самые разные тесты и тогда приходится вручную запускать все тесты, дабы убедится что ничто не сломано и все работает как планировалось. Вот это действие уже накладное и может вызывать большие потери времени разработчиков при запуске всех тестов и ожидании результатов, даже если предположить, что все тесты написаны качественно и проходят очень быстро.

В этой ситуации на помощь приходит Mighty Moose с подходом continuous testing (непрерывное тестирование). Мне логичным появление такой системы, с учетом того, что до этого набрали популярность и оправдали свое существование техники непрерывной интеграции и непрерывной доставки. Mighty Moose действительно оправдывает инсталляцию и занимаемую оперативную память.

Подробнее

Тестирование событий с помощью Moq

Вообще название статьи опять очень длинное на самом деле, что-то в духе: Тестирование сложных сценарий с событиями на примере Moq, связыванием StructureMap, построением объектов с помощью NBuilder, и проверки условий с помощью FluentAssertions. Но согласитесь, что это как-то чересчур и надо что-то выбрать одно, а то перечислять все технологии в заголовке плохо. Особенно когда рассматриваешь пример не простого приложения типа Hello World.

При тестировании real-life приложения возникает очень много вопросов по реализации и использовании технологий, которые обычно не рассматриваются в обзорных статьях, которые копипастятся друг у друга блогерами и агрегаторами статей. Надеюсь, данная статья прольет свет на некоторые аспекты использования упомянутых технологий.

Подробнее

Assert DSL 1.1

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

По науке, тесты являются документированием системы. Грамотно написанные тесты дают понять, как работает система, как ведет себя, причем читаться все это должно как готовая спецификация на поведение системы. Т.е. в идеале должен получаться связный и понятный текст. Это идеал, к которому постепенно приближаются методы тестирования, начиная от юнит тестирования и наиболее явно проявляясь в поведенческом/приемочном тестировании, когда сами тесты уже пишутся на языке бизнеса (в этом моменте вспоминаем Fitnesse).

При написании тестов не стоит скупиться на строчки кода и классы, важно только их правильно структурировать. Я считаю, что может быть вполне нормальной ситуация, когда у вас тестовый класс состоит только из одного метода – не надо этого стесняться, это гораздо лучше, чем классы на 20 экранов. HD экранов.

В общем, все должно быть направлено на максимальную ясность и четкость тестов, чтобы явно было видно все взаимосвязи. Чтобы можно было восстановить логику программы по одним лишь тестам. В дело читабельности пойдет не только Assert DSL (Domain Specific Language), но и именование файлов, подход Arrange Act Assert. Все это не новые подходы как оказывается, но широкой известности пока не получившие, судя по тому, что я вижу в окружающих меня проектах. Да и сам я натолкнулся на новые темы случайно, изучая исходные коды StructureMap.

Чтобы не томить, сразу расскажу какие основные шаги предлагаются для улучшения тестов:

  • Именовать тестовые файлы по основному методу, который тестируется.
  • Использовать DSL  для создания объектов, чтобы методы делать максимально лаконичными.
  • Стараться писать тесты в стиле «один тестовый метод – один assert».
  • Структурировать внутренности теста.
  • Создать и использовать Assert DSL.

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

Подробнее

Domain Specific Language для TDD

Domain Specific Language (DSL) – это язык специального назначения, который предназначен для решения какой-либо задачи в терминах самой задачи.

DSL — это не какой-то новый язык программирования в общем смысле этого слова. Вы создаете этот язык путем определения домена и разрешенных операций над доменными сущностями. Если вы разрабатываете приложения по философии Domain Driven Design, у вас в целом получается DSL  автоматически (но конечно не такой красивый, как если бы вы это делали целенаправленно). Это такой положительный побочный результат. Вы создаете правила и следуете им, так как они делают решение задачи легче. Вместо кучи строк кода, которые могут менять внутреннее состояние объекта, посылать сообщения, проверять значения и условия – вы пишете один оператор, который является значимым для задачи, а весь инфраструктурный код прячется.

DSL  должен быть декларативным и, по возможности, «текучим» (fluent interface – как пример, LINQ). Т.е. целю будет сообщить ЧТО надо делать, без упоминания КАК.

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

Кстати, SQL тоже может рассматриваться как вариант DSL, можно – так как «язык» создан для вполне определенной предметной области.

Собственно, на этом вводную часть статьи можно считать законченной. По теории можно шерстить вики и гугл, мы рассмотрим DSL на примере.

Подробнее