TDDigest e05

Интереснейший пост от компании Badoo об "Оптимальной параллелизации юнит-тество или 17000 тестов за 4 минуты" #ru

BDD in Action: Часть 1, Часть 2
Let your tests tell you when your code design sucks.
Why Not To Want 100% Code Coverage

Tips and tricks для  более эффективного использования phpUnit в слайдах PHPUnit best practicies. А так же, чем хорош phpUnit для создания mock-объектов - хорошая статья на Хабре. И, закрывая тему phpUnit, Parallel testing for phpUnit with ParaTest

TDD Javascript with Jasmine #video  #en

Статья Building the right software…right, It’s easy…RIGHT? с разъяснением разницы, что значит делать правильно и делать правильное. Путаница возникает, в основном, из-за использоания ATDD и BDD и TDD... Слишком много букв D, всё driven, только в какую сторону? Автор предлагает следующую структуру: сначала используется BDD - для определения целей, за ним - ATDD - для реализации целей, и потом TDD - для качественной реализации.
И небольшое видео, в котором объяняется разница между BDD и TDD:

Все знают мантру TDD "Red-Green-Refactoring", но как мы определяем, что рефакторинг нужен? И как найти золотую середину между минимизацией времени, затрачиваемом на разработку, и качеством кода, который придеся кому-то сопровождать в будущем?  Об этом речь в видео (а заодно и слайдах) Code Smells: Your Refactoring Cheat Codes #en #video #tdd #refactoring

Правильный подход к вопросу о unit-тестировании кода на stackoverflow. #en #php

О синергии тестируемости кода и дизайна приложения #video #en

Обсуждение трёх подходов к mobile testing:

TDDigest e04

В сегодняшней подборке материалов из мира TDD много видео интересных выступлений и интервью.
Видео с выступления #Сергея Теплякова на msswit "Тестируемая архитектура: моки, стабы, рефакторинг" #video #ru #mock #design #msswit

"TDD I learned..." - автор рассказывает о своих неудачных попытках писать тесты и полном непонимании бенефитов TDD до тех пор, пока не натолкнулся на мастер-класс Roy Osherove по TDD. Из видео, которое идет более 9 часов, автор вынес для себя много полезного, понял разницу между интеграционными тестами и юнит тестами, и впечатлился AAA-подходом (Arrange, Act, Assert):

This approach, by eliminating assert code intermixed with code that sets up or acts upon your objects, reduces smelly tests by separating what is being tested from all the other stuff.

Такой подход разделяет проверку (assert) результата, инициализацию объектов (arrange) и действия над ними (act), отделяя то, что нужно протестировать, от всего остального, тем самым устраняя дурной "запашок-с" тестов.

#en #tdd

Интересное интервью со Стивом Фрименом и Нэтом Прайсом, авторами книги "Growing Object-Oriented Software, Guided by Tests"

How do you start a new project with TDD? -  своеобразный подход к настройке среды для нового проекта. #en
BDD and Acceptance Testing with RSpec & Capybara #en #video #ruby #bdd #rspec
Drupal unit testing #en #drupal #php
Беседа о unit-тестировании в php #en #php #unit-testing
Юнит-тестирование в CakePhp #en #php #unit-testing #video
JUnit / TestNG Testing Spring Security With Spring MVC Test Framework

Инструменты

Mockery - ещё один mock-фреймворк для unit-тестов
atoum.js - стильный, модный, молодёжный ;) фреймфорк для тестирования PHP5.3+ теперь и для js
Swaks - швейцарский нож для тестирования SMTP
dotCover - тест-ранер, а так же инструмент для  сбора аналитики о степени покрытия кода тестами для VS от JetBrains (правда, платный)

TDDigest e03

Для начала разберёмся, как писать тестируемый код на javascript, и поговорим о том, как тестировать полученный код с помощью QUnit, а так же как наслаждаться процессом тестирования асинхронного javascript с помощью Mocha #javascript #en #mocha

Туториал о том, как писать тестируемый и поддерживаемый код на php, чего избегать в коде, а что, наоборот, является правильным подходом. Ещё серия туториалов, детально раскрывающих процесс юнит-тестирования с PHPUnit. Рассматриваются такие темы, как написание полезного теста (!), моки, стабы, dependency injection, тестирование закрытых методов класса (если уж очень нужно), перегруженные конструкторы и почему 100% покрытие кода не так уж и важно. #en #php #phpunit

TDDigest e02

Открывает второй выпуск tddigest немного филосовский пост "10 Правил Дзен-Программиста" от Christian Grobmeier #en #zen

Размышления на тему "Design for tests vs Design for API" #en #tdd #ruby

Очередные tips & tricks от php-девелоперов. В прошлый раз нам показывали, как тестить защищённые методы класса, а в этот раз говорят о том, как надо мокать singleton с помощью PHPUnit. Забавно, ведь даже на самом php.net красным написано: Ахтунг! Берегись синглтона! (шутки в сторону) А теперь серьёзно, когда может пригодиться такой подход? Я вижу один случай - есть база legacy кода, которую нужно поддерживать. Рефакторить код или вносить изменения без тестов -  смело, но глупо. Поэтому приходится иногда заниматься таким: мокать синглоны или чего ещё хуже выдумывать. #php #phpunit #antipattern

Сводка с фронтов от инфицированных тестами e01

Открывает первую сводку с фронтов удараников TDD хвалебная статья-ода "Not Using Test-First? You're Doing it Wrong." Автор не просто рассказывает, почему TDD - это круто, а пытается объяснить, как и чем улучшает test-first подход процесс разработки. #en #tdd
Продолжая тему полезности TDD "Why Testing Makes a Project Successful and You Can’t Afford to Deny It". Автор развивает мысль о полезности тестирования, эпично приводя статистику расхода времени и денег на поиск и фикс багов:

According to prweb.com, recent Cambridge University research found that, on average, software developers spend 50% of their programming time finding and fixing bugs and estimate that this costs the global economy $312 billion per year.

Да уж, не кисло. Не будь частью этой статистики, пиши теты! #en

Послушать, посмотреть, почитать

Накопилась очередная порция интересных ссылок на подкасты и не только.

tdd?

 

geek & poke

Visual Studio 11: запуск xUnit.Net без боли

Бета-версия одиннадцатой cтудии вызвала много охов и ахов. Чтобы там ни говорили, работать в ней приятно, хоть по началу немного необычно. На несколько шагов впёред продвинулась поддержка юнит тестирования. Чего только стоит новый Unit Test Explorer. Но я хочу рассказать о новой фиче, которая меня особо порадовала: Visual Studio 11 beta поддерживает сторонние фреймворки для тестирования! Ура! Ура! Ура! Теперь Unit Test Explorer можно сконфигурировать для запуска тестов xUnit.NET, MbUnit и NUnit. И даже не стоит расстраиваться, если фреймворка, который вы используете для тестирования, нет среди вышеперечисленных - ведь всего-то нужно написать свой адаптер (Unit Test adapter). Список существующих адаптеров можно посмотреть тут.
А пока, не откладывая в долгий ящик, запустим xUnit.net-тесты без TestDriven.Net.

Assert.True()

Отсюда

Ещё чуть-чуть о тестах

И еще одна небольшая заметка о TDD, точнее о том, что такое тест в контексте TDD.
Начинающие тэдэдэшники часто переусердствуют, стараясь тестировать всё и вся, забывая, что тест в TDD - это небольшой метод, проверяющий конкретное бизнес-правило. Акцент тут следует сделать на бизнес-правилах, они специфицируют поведение приложения, именно их нужно тестировать. С помощью TDD мы разрабатываем бизнес-логику. Не следует тестировать работу с БД, с файловой системой, сетевое взаимодействие - это уже совсем другой вид тестирования. Это интеграционные тесты. TDD позволяет нам быстро разрабатывать бизнес-логику, подтверждая работоспособность (или наоборот) кода мгновенным фидбеком. Если приходится специально что-то настраивать, чтобы запустить тест, и настройка занимает больше времени, чем написание самого теста, следует насторожиться. Метод для теста должен быть черным ящиком: известно только, что на входе, нужно удостовериться в правильности того, что на выходе.
В реальной жизни часто бывает так, что нужно взять выборку из БД и подсунуть данные методу для выполнения сложных расчетов. Для тестирования таких методов придумали Mocks, Fackes, Dummies & Stubs. Все эти технологии позволяют абстрагироваться от уровня физического взаимодействия, генерируя методы-заглушки. А методы заглушки возвращают тот набор данных, который им подсовываем. Чтобы было понятнее, вот простенький пример с Mock-библиотекой Moq.

Запахи TDD

Перевод статьи "TDD Process Smells "

Данный список запаховболее сфокусирован на выполнении принципов самого TDD процесса, чем на  содержимом тестов. Без сомнения, существует множество подобных запахов; я же выбрал наиболее часто встречающиеся по правилу 7 (+/- 2).

Библиотека

Steve Freeman, Nat Pryce. Growing Object-Oriented Software, Guided by Tests (скачать)
Test-Driven Development (TDD) is now an established technique for delivering better software faster. TDD is based on a simple idea: write tests for your code before you write the code itself. However, this "simple" idea takes skill and judgment to do well. Now there's a practical guide to TDD that takes you beyond the basic concepts. Drawing on a decade of experience building real-world systems, two TDD pioneers show how to let tests guide your development and “grow” software that is coherent, reliable, and maintainable.
Steve Freeman and Nat Pryce describe the processes they use, the design principles they strive to achieve, and some of the tools that help them get the job done. Through an extended worked example, you’ll learn how TDD works at multiple levels, using tests to drive the features and the object-oriented structure of the code, and using Mock Objects to discover and then describe relationships between objects. Along the way, the book systematically addresses challenges that development teams encounter with TDD—from integrating TDD into your processes to testing your most difficult features.

TDD: начало

Что такое TDD?
Это способ управления страхом в процессе программирования.
Да, мне гораздо спокойней, когда работоспособность моего кода подтверждена и подтверждается постоянно тестами. В любой момент времени я могу запустить тесты и проверить, все ли работает. Особенно актуально это, когда изменения вносятся в код, написанный пару-тройку месяцев назад, а то и ранее. А если этот код еще и чужой, то шансы поломать что-то возрастают многократно. Имея хороший набор тестов можно безбоязненно и безболезненно вносить изменения в код. Говоря "хороший набор тестов" я намеренно не указываю число в процентах, потому что считаю test coverage весьма относительной метрикой. Стопроцентное покрытие - исключительно утопия. И та еще тема для холивара :) Тестов должно быть столько, сколько требуется для уверенности в вашем коде и спокойного сна, если представить, что каждый ваш проект - система обеспечения АЭС ;)
К чему стремится TDD?
К чистому коду, который работает.
Ключевое слово здесь - чистый. Код, который работает, может написать каждый. И зачастую такой код - выходец из семейства "говнокодовых". Думаю, такой код в начале тернистого пути совершенствования навыков программирования писали все. Но есть несколько вещей, которые заставляют двигаться от кода, который работает, в сторону "чистого кода, который работает" - начинаются сложности при поддержке кода, внесении изменений, расширении системы... признаки того, что все катится в сторону антипаттерна Big ball of mud :(
Каковы правила TDD?
Красный - зеленый - рефакторинг

Эти правила просты, как дважды два:
1) Красный - пишем тест. Не факт, что он заработает сразу (или даже скомпилируется). Напротив, это тревожный знак. Ведь тесты мы пишем всегда перед написанием кода. «Тест, написанный после кода, ничего не стоит и является только обузой.»
2) Зеленый - заставляем тест работать, создавая при этом минимум кода. О чистоте и порядке на этом этапе задумываться еще рано. Тест должен работать. И работать быстро. Вот что главное на данном этапе. Минимум усилий. Ничего лишнего. Тут мы создаем код, который работает.
3) Рефакторинг - наводим порядок. Убираем дублирование и остальные запашки. После каждого действия запускаем тесты, проверить, ничего ли не поломалось. Время создавать чистый код, который работает.
И кто это все придумал?
Тестирование имеет довольно длинную историю, уходя вглубь веков. Первые упоминания о тестировании можно найти в 1975 (в "Мифическом человеко-месяце" Брукса). А сама методология Test-Driven Development и ее основные принципы были сформулированы Кент Беком в книге "Extrime Programming Explained", увидевшей свет в 1999 году. С тех пор и понеслось :)
Что нужно, чтобы начать?
Нужно немного - желание, храбрость, терпение и фреймворк для тестирования под платформу, на которой вы программируете. Или можете сами его написать, как это делает Кент Бек. Заодно и попрактикуетесь:)
А еще?
А еще можно (нужно) искать тут:
Кент Бек. "Экстремальное программирование: разработка через тестирование"
Roy Osherove Understanding TDD (видео, en)
Джерард Мессарош «Шаблоны тестирования xUNIT»
Джошуа Кериевски. "Рефакторинг с использованием шаблонов"
М. Фаулер "Рефакторинг. Улучшение существующего кода."

SqlCE 3.5 to 4.0 Converter

Недавно (в июле этого года) вышла новая версия MS Sql CE, в которой был изменен алгоритм шифрования (стал использоваться SHA-2). Это означает, что для работы sql ce 4 с бд, созданной сервером версии 3.5, ее нужно предварительно переконвертировать. Для это в API предусмотрен специальный метод, поэтому особого труда конвертирование не вызовет.
Давайте напишем конвертер для файлов баз данных в формате slq ce 3.5 в формат slq ce 4.0.
Писать будем на C# в TDD-стиле, использовать VS 2008, тестировать в xUnit (последнюю версию можно скачать с codeplex). Когда вы используете TDD, не нарушая основных принципов ( а их всего три - RGR (красный-зеленый-синий): пишем тест, пишем код, рефакторим) и порядка их следования, то получаете автоматически приятные бонусы в коде.

Warning! Этот пост нужно рассматривать как пример по разработке в стиле TDD для начинающих.