TDD *

Итак, моя последняя запись: стартап-ловушка (здесь её перевод — прим. переводчика) наделала много шуму. Среди людей, выражающих согласие и поддержку, нашлась и группа людей, которая была категорически не согласна. Я не буду здесь резюмировать все разногласия, ибо в этом месяце я уже исчерпал свой лимит ругательных слов. Но одним альтернативным мнением я проникся и считаю нужным его обсудить.
Речь о старом конфликте «прагматизм против догматизма».

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

Идея данной заметки — как гипотезы — появилась уже довольно давно, и все как-то не получалось… Но вот «на днях» (к моменту публикации — уже неделях) увидел подтверждение своего предположения что называется «из первых рук» (см. Kent Beck's answer to Unit Testing: Did the notion of using setup() and teardown() methods in test fixtures originate from JUnit?) и решил-таки воплотить эту задумку.

Думаю, что все знают, что такое модульные тесты, все знают или, по крайней мере, слышали, что такое непрерывная интеграция, и многие программируют на C++. Но я столкнулся с тем, что в интернете не так много информации о том, как же это все объединить и заставить работать вместе. Эта статья является попыткой дать новичками пошаговую инструкцию, которая позволит сделать первый шаг в создании модульных тестов для C++ проектов и организовать покоммитный прогон модульных тестов при помощи CI сервера.
Update: План:

1. Напишем HelloWorld
2. Настроим сборку HelloWorld на Jenkins
3. Напишем модульный тест для HelloWorld
4. Настроим прогон модульных тестов на Jenkins

Внимание: много букв и скриншотов, половина из которых избыточны. Особенно для тех кто уже в теме.

Google Test — это фреймворк от Google для юнит-тестирования кода на С++. Общей архитектурой он слегка напоминает общепринятые boost::test и CppUnit, хотя слегка отличается в деталях (как по мне — в лучшую сторону). Большая обзорная статья этого фреймворка уже как-то пробегала на Хабре, но нынче она в каком-то побитом состоянии (код не отображается), да и кажется мне слишком сложной для начала работы. Поэтому я коротко опишу «Hello world» на Google Test, указав на несколько потенциальных проблем, с которыми вы можете столкнуться, используя Google Test при разработке под Visual Studio.

Эта статья представляет собой хороший теоретический материал о TDD для тех, кто об этом ещё ничего не знает.

Однажды мне надоело, что исправление багов занимает у меня больше времени, чем разработка приложения, и в поисках путей решения я пришел к TDD — Test-driven development (Разработка через тестирование).

В это статье рассказывается как делать первые шаги в XCode 4.5, используя unit test-ы, при разработки приложений под IOS.

Статья предназначена для новичков, в ней не содержится информации для зубров разработки.

Coding Dojo (кодинг додзё) — это встреча, на которой программисты (а теперь все чаще и тестировщики) вместе бьются над какой-нибудь задачей. Помимо фана, разработчики занимаются тем, что принято называть Deliberate Practice — регулярная практика, целью которой является постоянное повторение какого-то упражнения с целью повышения навыка. Именно поэтому и появилось название Dojo, потому что

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

Ну а под катом можно прочитать об истории появления, основные принципы и многое другое.

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

Я столкнулся с командами в нашей организации, которые пытаются внедрить Test Driven Development (TDD).Иногда одному или двум разработчикам удается применить его без посторонней помощи, но у большинства этого не выходит. Чтобы лучше понять проблему я провел опрос среди членов команды и обнаружили, что даже после обучения еще многое предстоит сделать. Эта стратегия была разработана, чтобы помочь любому внедрить TDD в организации, хотя некоторые из идей применимы лишь для средних и крупных компаний.

С моим первым опытом TDD на меня снизошло озарение. Последние 2-3 года со всех сторон атакует информация «TDD это хорошо», «Тебе нужно TDD», отчего мозг инстиктивно начинает противиться насаждаемой информации. До этого я ни разу в коммерческих проектах не практиковал TDD, но когда начал — все встало на свои места. Хочу показать одну интересную на мой взгляд точку зрения на автоматизированные тесты, которой еще ни разу ни от кого не слышал.

Многие слышали про Selenium WebDriver — один из самых популярных инструментов для написания приёмочных/интеграционных тестов.


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

Поэтому мы решили выделить этот повторяющийся код в отдельную библиотеку. Так на свет появился Selenide.

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

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

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

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

Когда разработчики впервые открывают для себя прелести разработки через тестирование — это как переход в новый, лучший мир, где гораздо меньше стресса и незащищенности. Этот прекрасный опыт действительно стоит отпраздновать. Но осознание преимуществ тестирования — только первый шаг к просветлению. Самое сложное — понять что НЕ нужно тестировать.

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

Я уже писал на Хабре о Codeception — фреймворке для тестирования приложений на PHP. Если вы никогда раньше не писали тестов для вашего приложения, вам обязательно стоит взглянуть на Codeception. Он очень прост в использовании и сделан специально, чтобы уберечь разработчиков от рутины.

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

Есть такая конференция ADD (Application Developer Days) на которой любят всякие архитектурные штуки для разработки ПО обсуждать, обычно эти штуки заканчиваются тоже на xDD — DDD, TDD, MDD и т.д.

Вот к примеру на прошлой конференции задались вопросом, а что такое DDD (Domain Driven Design)?
А Николай Гребнев из CUSTIS — встал и ответил.

Видео доклада:

В предыдущих статьях на примерах JUnit и TestNG я упоминал о test-driven development(TDD) и data-driven testing(DDT). Но есть еще один активно набирающий популярность подход, behaviour-driven development(BDD). Это такое развитие TDD техники, при котором на тест смотрят не как на тестирование каких-то компонентов системы, а как на требования к функционалу. Если TDD оперирует такими понятиями, как тест или метод, то для BDD это спецификация и требования. Про эту технику уже говорили на хабре ранее:

• Эволюция юнит-теста,
• Экстремальное программирование, знакомство с Behavior Driven Development и RSpec

Этот подход применим используя и JUnit, и TestNG. Но есть и другие инструменты заточенные именно под BDD. В этой статье я расскажу про такой фреймворк. Называется он Spock Framework и сочетает в себе не только принципы BDD, но и достоинства Groovy. Да-да, именно Groovy. И хотя используется Groovy, используется он и для тестирования Java кода. Примерами использования могут служить Spring, Grails, Tapestry5. Интересно? Тогда читаем дальше.

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

А зачем вообще это нужно?

Добрый день уважаемые посетители habrahabr.ru!

Давным-давно, когда я работал в одном из стартапов, где я был основным иницатором и продвиженцем внедрения TDD, у меня возник спор с моим «техническим директором» (если его можно было так назвать) на тему того как TDD влияет на получаемый в итоге код. Он сделал одно простое замечание, на которое я не смог тогда найти, что ему ответить – «При подобном подходе к разработке в коде появляются дополнительные интерфейсы (я практиковал подход к тестированию с помощью Mock'ов, Stub'ов и подмены реализаций интерфейсов) и уровни, усложняющие и замедляющие код».
Что бы Вы ответили?