TDD *

Оригинал: www.infoq.com/articles/atdd-from-the-trenches

ATDD с передовой

Разработка через приемочное тестирование для начинающих

Если вы когда-нибудь бывали в такой ситуации:

Тогда эта статья для вас — конкретный пример того, как начать разработку через приемочные тесты (Acceptance-test driven development) в действующих проектах с легаси кодом. В ней описан один из способов решения проблемы технического долга.
Это пример из реального проекта, со всеми изъянами и недостатками, а не отполированное упражнение из книги. Так что надевайте свои берцы. Я буду использовать Java и JUnit, без всяких модных сторонних библиотек (которыми, как правило, злоупотребляют).
Предупреждение: Я не утверждаю, что это единственный Правильный Путь, существует много других “стилей” ATDD. Так же в этой статье не так много чего-то нового и инновационного, здесь просто описаны хорошо себя зарекомендовавшие подходы и опыт из первых рук.

Недавно в нашей фирме устроили лекцию «Engineering Practices» и это оказалось введением в TDD.
О нет, только не это! «Иногда они возвращаются» (с) Стивен Кинг

На прошлой работе мы потратили 3 года на попытку внедрить эту методику. Это было мучительно. Менеджмент искренне верил в то, что TDD решит проблемы фирмы. Реальность разительно несоответствовала этому. Все это будило затертые воспоминания о Советской эпохе. Вспоминались висящие на стенах плакаты «Вперед к победе коммунизма» и фразы вроде «Учение Маркса всесильно потому, что оно верно».


Так что же не так в консерватории c TDD?

Трудно одним заголовком сформулировать, чем же является Galen Framework. Все началось с того, что у меня возникла потребность тестировать сайты в различных браузерах и проверять: не поехала ли разметка, например, в том же Internet Explore или Chrome. Затем возникла мода на Responsive Web-Design, и пришлось вручную менять ширину браузера и проверять, как отображаются сайты. И, хотя все это время были WebDriver и Selenium Grid под рукой, так и не получалось нормально тестировать верстку сайта в Java коде. Одна из идей была: делать скриншоты в разных браузерах в Selenium Grid и затем собирать их все в один большой отчет, по которому один из тестировщиков обязан пробежаться глазами и, в случае обнаружения несоответствий, рапортовать о дефекте. К сожалению, вся эта затея долго не продержалась. Тестировщикам стало лень листать огромный отчет и сравнивать скриншоты, и они все равно пропускали мелкие дефекты. А затем пошли требования внедрения во всех сайтах Responsive Design. И вот тут появился Galen Framework. Решение оказалось простым: проверять размер и расположение элементов относительно друг друга. Для этого понадобился специальный язык Galen Specs, который было бы легко читать и понимать.



Если коротко, Galen Framework — это специальный язык и инструмент для тестирования отображения сайта в браузере. Он позволяет тестировать адаптивный дизайн, а также проводить кросс-браузерное тестирование сайта.

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

Сразу оговорюсь, что примеры приводятся применительно к языку C# и платформе .NET. Соответственно, в других языках/платформах подходы и реализации могут отличаться.

Итак…

Некоторое время назад я принял решение потихоньку внедрять в свою практику автоматизированное тестирование и TDD. Признаюсь честно, получалось все это с переменным успехом. Но то, что жить стало гораздо интереснее – это неоспоримый факт. Со мной стали происходить разные приключения. И, как во всех приключениях, иногда становилось немного страшно. Об одном таком случае я и хочу рассказать.

В проекте, в котором я принимал участие, потребовалась плотная работа с временными интервалами от минуты до года. Плох (или наоборот слишком хорош) программист, не написавший в своей жизни ни одну библиотеку работы с датами. Я не хуже и не лучше других, поэтому решил размять мозги и создать немного кода.

Продолжение. Начало здесь.

Как все это использовать?

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

От переводчика: так сложилось, что в русскоязычном интернете мало информации о TDD и в основном описываются механические действия разработчика. Главному же – идее – уделяется совсем мало внимания. Эта статья является попыткой восполнить этот пробел. Важно отметить, что она не для тех, у кого нет времени на тесты, и тем более не для тех, кто не осознает важность слабосвязанной архитектуры. Статья (оригинал) адресована тем, кто делает или собирается сделать первые шаги в TDD.

Я все больше в своей практике пытаюсь использовать автоматизированное тестирование. Стараюсь при этом не плодить инструменты и библиотеки, обходиться простыми подходами. Не так давно, я задумался о том, как протестировать CSS-файлы. Поиск по Интернету выявил следующие точки зрения на этот вопрос:

1. Тестирование CSS не имеет смысла, так как это декларативный язык, а его результатом является сверстанное изображение страницы, которое можно оценить лишь визуально.
2. Протестировать CSS можно с помощью снятия битмапов с сгенерированной страницы и сверка ее с эталонным изображением. Для этого даже есть некоторые инструменты.
3. Нашлась некоторая библиотека CSS-Unit.

Должен сказать, что все варианты мне не понравились. В конечном итоге мне удалось протестировать CSS используя текстовый редактор, Firefox + Selenium IDE и… и больше ничего.

Добрый день хабр.
Вчера вышла версия 1.1.0 test.it — фреймворка для тестирования js кода.
Он, наконец, обзавёлся функционалом, отсутствие которого делало его неполноценным:

• Асинхронные тесты/группы
• Запуск отдельных тестов/групп

А так же прочими мелочами.


Кто не любит много слов — Сайт на котором можно увидеть код в действии, GitHub, Wiki

Добрый день хабр.
После моей статьи о test.it прошла вечность неделя. И как я не планировал растянуть этот срок хотя бы на месяц, но пришло время для новой публикации.
Картинка для привлечения внимания:

С того времени библиотека (во многом благодаря хабравчанам) обросла новым функционалом.
А ввиду того, что синтаксис, приведённый в прошлой статье, в текущей версии работает не полностью, откладывать эту статью ещё на 3 недели у меня нету права.

Кто не любит много слов — Сайт на котором можно увидеть код в действии, GitHub, Wiki

Здравствуйте. Признаюсь честно, я пишу тесты редко. Т.е хотел бы чаще, но все как-то не получается. Вроде и руководство в принципе не против даже, но все равно находятся задачи посрочнее и поважнее. Тем не менее на днях заглянув в redmine обнаружил что задач практически нет (точнее они были, но требовали сперва дождаться бэкэнда).
Что ж, самое время вспомнить про тесты (конечно нужно было раньше о них думать, но лучше поздно чем никогда).
Вообще я до этого уже пробовал писать тесты, в том числе и на бэкэнде, а конкретно django. Я еще тогда подумал что было бы здорово запускать тесты из консоли а не в окне браузера. Ну а поскольку с недавнего времени я активно слежу за развитием angular, то почему бы не посмотреть как это сделано у них. Тем более как-то краем глаза я зацепил момент, что там тесты как раз запускаются в консоли. Плюс к тому же с нуля разбираться в премудростях тестирования не хотелось и я решил взять какой нибудь готовый проект с тестами, посмотреть как оно сделано, и погонять собственно тесты на нем. Мой выбор пал на angular-ui, а точнее на один из его модулей ui-utils.

Скачиваем, заходим в корень видим папку test а в ней файл karma.conf.js
Да и в самом ридми написано, что тесты запускаются так karma start —browsers ….
Гуглим karmajs и находим то что нам нужно karma-runner.github.io/0.8/index.html
Утилита для тестирования. Итак что она может?

• Запускать тесты из консоли
• Автоматически прогонять все тесты при каждом сохранении!!!
• Возможность писать тесты на множестве фреймворков, таких как jasmine, qunit и др.
• Прогонять тесты сразу на нескольких браузерах. (в том числе виртуальных, например fantomjs).

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

Вступление

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

Юнит. Что это такое?

Unit testing принято переводить на русский язык как модульное тестирование. Однако слово «модуль» имеет несколько другой смысловой оттенок, ассоциирующийся со схемой развертывания. Поэтому во избежание ненужных ассоциаций будем использовать англицизм «юнит». Еще раз вспомним, что такое юнит в рамках терминологии юнит тестирования:

Юнит – это фрагмент кода, дающий в данном окружении при определенных входных данных определенные выходные данные.

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

Не нашла в интернете пошаговой русскоязычной инструкции о том, как настроить SpecFlow на работу с русскими спецификациями. Да и вообще нет русской инструкции о том, как начать работать со SpecFlow. Зато обнаружила некоторый скепсис у других автоматизаторов по поводу того, что это можно сделать легко и просто, однако предложенные альтернативы мне не приглянулись в далекой перспективе (просмотр тестов с веба специалистами технической поддержки). Мне нужен именно SpecFlow и именно по-русски!

Я все-таки как-то разобралась, и, чтобы другие не сомневались, что это не так уж и сложно сделать, и не набивали собственные шишки, делюсь своей инструкцией. Она прежде всего предназначена для тестировщиков-автоматизаторов, поэтому может содержать некоторые очевидные для программистов моменты.

Эта статья полезна для тех, кто:

• оценивает перспективы применения Specification by Example (BDD) подхода к автоматизации тестирования, и хочет описывать фичи и сценарии на русском языке, и хочет оценить scope работ;
• хочет как можно быстрее начать применять BDD в своем проекте.

Эта статья бесполезна для тех, кто:

• сам знает как это просто делается;
• готов потратить несколько часов работы + владеет английским языком достаточно хорошо, чтобы самому разобраться в инструкциях.

Модульные тесты используются при разработке программного обеспечения. Они могут быть созданы как после написания исходного кода, так и до этого, все зависит от ваших предпочтений и вероисповедания, либо предпочтений вашей компании. Разработка через тестирование(TDD) вызывает довольно спорное впечатление. Кто-то считает, что это довольно бесполезная вещь, однако склонен не согласиться. Бесполезным TDD назвать точно нельзя. Создание теста покрывающего предполагаемое изменение в программе, а затем написание кода который бы позволил пройти этот тест, заметно упрощает разработку. Модульные тесты так же используются для проверки уже созданного функционала. Однако достичь 100% покрытия кода программы модульными тестами практически невозможно.

Дайте-ка угадаю: вы согласны с тем, что писать тесты — это хорошо. Это повышает надежность системы, ускоряет разработку, проект с хорошим тестовым покрытием поддерживать легко и приятно, а TDD — это вообще почти идеал процесса разработки. Но не у вас в проекте. То есть, оно клёво, но, к сожалению, сейчас столько работы — просто завал. Куча задач, одних только критических багов — два десятка, плюс надо срочно дописать этот модуль и еще написать письмо заказчику… Так что тесты, наверное, будем прикручивать уже в конце, если время останется. Или в следующем проекте. Нет, ну там точно полегче будет. Скорее всего.

Как, узнали ситуацию?

Так вот — чушь всё это. Сфера ИТ — бесконечна, как вселенная, куча работы будет всегда. Можно или начать писать тесты прямо сейчас, или не сделать этого никогда. Я тут набросал короткий план, как начать это делать за 10 шагов, по шагу в день, по 10 минут на шаг. И когда я говорю «10 минут» я имею в виду не «3 с половиной часа» и не «ну сколько-то времени, лучше побольше», а именно 600 секунд. Если у вас нету в день 600 секунд свободного времени — срочно меняйте проект, работу, профессию, страну проживания (нужное подчеркнуть), потому что это не жизнь, а каторга какая-то. Поехали.

Недавно я задался вопросом поиска инструментария для разработки мобильных приложений на html/css. Из требований были: доступность, легковесность, простота настройки. Выбор пал на встроенный Node менеджер NPM. NPM содержит
инструментарий для базовых тасков типа install и запуска пользовательских скриптов. Также NPM не такой громоздкий, как Grunt и не требует адаптации модулей под себя, т.к. запускает модули с командной строки.

Хотел бы сказать пару слов о книге Professional Test Driven Development with C#. Выбрать книгу по популярным технологиям и техникам программирования не так сложно. На каждом форуме написано, что если хочешь познать .NET – не обойтись без Рихтера. Сложнее с менее популярными темами. Итак, TDD…

В этой статье я хочу поделиться опытом создания инфраструктуры для интеграционного тестирования веб приложения. Приложение построено на платформе .Net и состоит из ASP.NET MVC приложения и базы данных на MSSQL

Задача интеграционного тестирования формулировалась следующим образом: автоматизировать развёртывание приложения и выполнение тестов пользовательского интерфейса, чтобы можно было быстро убедиться в том, что устанавливаемая версия приложения успешно отрабатывает все необходимые тестовые сценарии.

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

Поскольку интеграционное тестирование позволят имитировать действия пользователя можно сказать, что оно позволят проверять факт того, что такой-то пункт ТЗ успешно выполнен. Если создать тесты для каждого пункта ТЗ (то получим программу и методику испытаний — ПМИ :) и автоматизировать их, то количество успешно выполненных тестов будет означать реальную информацию о том, на сколько процентов исполнено ТЗ. Иначе оценка состояния системы будет выглядеть следующим образом:
— Ну как у нас сегодня система, если одним словом?
— Если одним словом, то… работает.
— А если в двух словах?
— А если в двух словах, то не работает.

Что должно проверяться при таком тестировании:
— Компиляция и сборка приложения
— Процедура установки или обновления приложения:
— Установка новой или обновление существующей базы данных
— Установка нового ASP.NET приложения
— Выполнение тестовых сценариев в каждом из которых:
— Система подготавливается для выполнения сценария. Поскольку каждый сценарий имеет предусловия надо подогнать систему под эти условия. Например если для сценария надо чтобы в системе бы пользователь создавший три заказа, надо как-то получить в базе денных пользователя и три его заказа.
— Выполняется тестовый сценарий через эмуляцию действий пользователя в браузере.
— Система возвращается в состояние, которое было перед выполнением сценария, фактически в состояние сразу после установки приложения
— Составление отчёта о качестве приложения
— Сборка инсталяционного пакета, содержащего приложения с известным качеством.

Даже если код тривиален, вы всё равно должны его тестировать.
Пару дней назад, Роберт Мартин опубликовал пост «Прагматичность TDD», (здесь лежит перевод — прим.переводчика) где он рассказал о том, что не тестируют абсолютно весь код. Среди исключительных ситуаций, когда не стоит применять TDD, дядя Боб упоминает написание GUI-кода, и я вижу смысл в таких утверждениях, но среди исключений есть парочка, на мой взгляд, нелогичных.

Человек — ужасно ленивая зараза. Нет, ну я не о вас, конечно! Ну что вы! Я так, о себе. О 99% человечества. Но не о вас, нет. Вы сами за себя решайте. Но вот те 99%, так уж вышло — ужасно ленивы. Кто-то это отрицает, кто-то мирится, кто-то борется. А лично мне кажется, что это такая же неотъемлемая черта нашего вида, как, например, две руки и две ноги. Можно убиваться, что у нас нет крыльев или жабр — а можно научиться хорошо пользоваться тем, что есть. Так же и с ленью. Зачем её отрицать? Надо её использовать по-полной. И вот тут, поскольку мы с вами имеем кое-какое отношение к ИТ, давайте посмотрим, как с этим обстоит дело в нашей профессии.