пятница, 30 марта 2012 г.

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

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

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.  
В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода.
Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT.

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который заменяет реальный объект, от которого зависит SUT, в тестовых целях. 
Когда нам нужно использовать double?
  • Низкая скорость выполнения тестов с реальными объектами (если это, например, работа с базой, файлами, почтовым сервером и т.п.)
  • Собственно необходимость запуска тестов независимо от окружения (например, на машине у любого разработчика)
  • Система, в которой работает код, не дает возможности (или дает, но это сложно делать) запустить код с определенным входным набором данных.
  • Нет возможности проверить, что SUT отработал правильно, например он меняет не свое состояние, а состояние внешней системы. И там эту проверку сделать сложно.
Gerard определяет следующие типы дублеров:
  • Dummy  
- это объекты, которые передаются в методы, но на самом деле не используются. В основном, это параметры методов (если конечно, они не влияют в тесте на то, что мы хотим проверить). Иногда это просто NULL
  • Fake
- это объекты, которые имеют внутреннюю реализацию, но обычно она сильно урезанная и их нельзя использовать в готовом коде.
  • Stubs
- обеспечивают жестко зашитый ответ на вызовы во время тестирования. Применяются для замены тех объектов, которые обеспечивают SUT входными данными.   Также они могут сохранять в себе информацию о вызове (например параметры или количество этих вызовов) - такие иногда называют своим термином Test Spy. Такая "запись" позволяет оценить работу SUT, если состояние самого SUT не меняется.
  • Mocks
- объекты, которые настраиваются (например специфично каждому тесту) и позволяют задать ожидания в виде своего рода спецификации вызовов, которые мы планируем получить

Из всех этих doubles только Mock'и работают на верификацию поведения. Остальные, как правило, используются для проверки состояния. В момент выполнения метода SUT использование doubles не отличается. Но Mock'и требуют настроек перед запуском и позволяют оценить процесс выполнения.

В классическом варианте модульного тестирования реальные объекты везде, где это возможно (за исключением случаев описанных выше). В мокирующем (mockist) варианте - мокируется все, кроме того объекта, который тестируем (SUT)
Какой использовать? Плюсы и минусы есть у обоих.

Остановимся на минусах.

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

При мокировании всего и вся может возникнуть другая проблема: поведенческие тесты жестко фиксируют внутреннюю реализацию SUT. Что и как вызывается, с какими аргументами, какое API используется и тп Все это создает трудности при рефакторинге и возможных изменениях в SUT - вместе с кодом все тесты придется писать заново.

Что проще, выбирать вам. Из своего опыта скажу, что классика мне ближе и понятней (радует, что и Martin Fowler того же мнения). А вот с мокированием как то не срослось. 

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

А вообще "используйте mocks только, когда это действительно нужно"


Источники:
Mocks Aren't Stubs (Martin Fowler)
Test Double (Gerard Meszaros)

Некоторые фреймворки для мокирования:
Java:     mockitojMock
.Net      Rhino Mocksmoq
C++      googlemock
Python  pyDoublesmockito-python

Интересно по теме от Roy Osherove "The Three Values of a Good Isolation Framework"
Свеженькое по теме "Using Mocks or Stubs, Revisited"


Вам может быть интересно:
"А вы не любите TDD, как не люблю его я?"
"Software-Engineering Myth Busters (покрытие кода тестами, TDD, организация и распределенные команды)"

Забавные факты:
Что вы знаете о моках? Оказавается, есть целые mock-города для тестирования автономных автомобилей. Вот про один из них.

"мотивированный конь - это ни разу не ферзь" или IT talk SPb - 3

Ставший уже традиционным отчетик после очередного IT talk-а.
Он будет очень коротким, потому что пересказывать Сашу Орлова бессмысленно :) (в заголовке, кстати, один из его знаменитых перлов)

Его надо слушать, а слушать его в живую вдвойне приятно. Очень много обращений к реальным кейсам, поэтому информация вызывает доверие (если конечно можно не доверять Саше :) Хотя тем, кто следит за его докладами большинство этих кейсов знакомы. Но повторение - мать учения!

Общались на тему решения конфликтов. Саша предлагает использовать алгоритм конструктивной коммуникации.

Такую коммуникацию определяют:

Для себя отметил важность своего рода ретроспективы после решения проблемы: нельзя давать фиксировать неправильное поведение. Особенно важно, если ты пошел на какие-либо уступки при этом.


Очередное большое спасибо DataArt'у за организацию. Следующая встреча будет посвящена мобильной разработке. Следите за анонсами.

Полезные ссылки:
Happy PM
"Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения"

PS отдельное спасибо Лене за пирожки с вишней :)

пятница, 23 марта 2012 г.

Отзыв по вебинару "С чего начинается автоматизация"

Запись вебинара можно посмотреть на портале об автоматизированном тестировании ПО.

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

  • зачем нужна автоматизация
  • как ее продать (для разных видов разработки: продуктовая, заказная, внутренняя)
  • что нужно знать для успешного ее внедрения
  • какие инструменты лучше использовать
  • с чего начать
  • полезные книги
Миша - молодец :)

Появившиеся у меня вопросы:

Про "что нужно знать и уметь". Миша отметил, что нужно и OOP, и (на выбор) Java, C#, Python (тоже мой любимый :), и администрирование, и Linux и еще кучу всего + навыки тестирования. Это ж где такой комбайн найти :) ?

Может проще поработать с разработчиками и часть их мозгов в этом направлении использовать?
Особенно это актуально из-за "кастового" вопроса - сколько раз слышал про то, что разработчик не хочет работать тестировщиком (даже автоматическим).
Как вариант - помогать развиваться ручным тестировщикам. Но Миша про это говорил.

Тестовые скрипты - это тоже код, и тоже может содержать ошибки. Это надо учитывать. Тесты на тесты - это круто (было такое)

Интересно было бы узнать про соотношение разработчиков и автоматизаторов из опыта Миши. То что автоматизаторов сейчас нет (или мало), это понятно. А сколько их нужно, чтобы не догонять постоянно уходящий поезд из новых фичей?

четверг, 22 марта 2012 г.

Mikado - работаем с legacy code

    Обычно изменение, даже самое простое, сделанное в legacy коде, сопровождается массой неприятных вещей: ошибками компилятора, "покрасневшими" приемочными тестами (СЛАВА ВАМ, если они у вас есть!) и тд. Вы исправляете эти места, начинают взрываться новые, и это продолжается бесконечно и кажется неконтролируемым. В какое то момент вам начинает казаться, что проще все сделать заново, чем исправлять существующее. Да-да, обычно так и происходит, чтобы вы не говорили :)

Недавно наткнулся на интересный метод, который предлагает простое решение этой проблемы. Метод называется Mikado. (Обожаю я японские слова, но тут японцы не поучаствовали. Ну, разве что слово у них взяли: термин попал из игры с палочками)



В чем заключается этот способ?

Давайте сначала пару слов о том, что такое  legacy код? Одно из определений гласит, что это код, который написали не вы, но вы сейчас за него ответственны. Michael Feathers в своей книге "Working effectively with legacy code" определяет код как legacy, если он написан без тестов. Собственно это определение сейчас и является основным.

Mikado работает как с кодом, который "по-настоящему" legacy = на него нет тестов (упустим за рамки данного обсуждения сам факт недопустимости такой ситуации), так и с кодом, на который тесты есть. Зачастую, даже если тесты есть, их качество или качество кода не позволяют добавлять новый функционал безболезненно. Тогда Mikado (Микадо) для вас.

Итак, у вас есть цель: добавить новый функционал, и код который писали не вы, или писали в состоянии аффекта :)

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

А вот если что-то взорвалось: не компилируется или тесты не прошли, начинаем использовать Микадо.
Берем ручку и листок бумаги/маркер и доску и рисуем кружок - нашу цель. Она и будет нашей Микадо (так называется самая крутая палочка, которую надо вытащить в игре). Дальше рисуем кружки с возникшими проблемами.  Получаем  Микадо-граф. Дальше делаем невероятное - откатываем изменения и возвращаем работоспособность кода. Ужасно правда? :) Вы ведь так старались, что то делали, а тут все взять и откатить. "Вдребезги?! — Конечно, вдребезги. — Да я тебя!!!" (с) "Операция Ы и...". Но в этом то и соль: вы постоянно поддерживаете работоспособность кода и маленькими шажками двигаетесь к цели. После отката пытаемся решить одну из проблем, которую мы обнаружили на предыдущем шаге. Не получилось? Опять проблемы? Снова рисуем кружочки с вновь обнаруженными проблемами,  и снова откатываем! Переключаемся на решение одной из свежих проблем и тд, до тех пор пока не будет изменения, которое не поломает код или тесты. После этого начинаем спускаться вниз по графу, постепенно решая все найденные проблемы. В итоге вы сможете сделать то изменение, которое вам требуется для достижения вашей цели.

Для примера полученного в итоге дерева, приведу картинку из книжки про Микадо (решалось все сверху-вниз)



Ключ к изменению любой системы - это изменить все ограничения, которые не дают сделать желаемое.

Алгоритм получается такой:

Обратите внимание на то, что для решения проблемы предлагается использовать самый простой ("деревянный") способ. Не надо пытаться тратить время на предварительный анализ. (Забавно, я обычно предпочитаю немного подумать) Считается, что все грабли будут собраны последовательно, и также последовательно решены. Главное чтобы, не получилось как на знаменитой картинке Макса Дорофеева:

Сами авторы метода (Daniel Brolund, Ola Ellnestam) не претендуют на уникальность подхода. По своей сути, это переработанные идеи из книг Мартина Фаулера, Майла Фезерcа, Роберта С Мартин-а. Кроме того, в книге они указывают на то, что Mikado не является лучшим способом достижения цели. Просто он самый простой и рабочий. С помощью него, вы достигнете своей цели идя одним из множества возможных вариантов. Запомните: "лучшее - враг хорошего".

Я сознательно не давал ссылок на сам источник информации о методе Микадо выше :)
А между тем, я очень рекомендую про его почитать. В книжке (версия на IT-eBooks), кроме описания самого метода (на простом примере), вы найдете много полезной информации: способы рефакторинга, design principals и их сочетание с Mikado. По-моему, это неплохая выжимка всех практик от классиков упомянутых выше, из их знаменитых книг. И это всего в 250 страниц!

Кстати, в книжке рекомендуется сочетать Mikado c техникой Pomidoro. Последнюю я сейчас практикую - реально помогает.

вторник, 20 марта 2012 г.

IT Talk SPb - 3-я встреча, анонс

DataArt похоже решил не сбавлять темпа и продолжает развивать тему IT Talk-ов в Питере.
На новую встречу, которая ожидается 29 марта, в качестве спикера приглашен Александр Орлов.

Не пропустите, это будет интересно! Саша очень хороший рассказчик и тема интересная: "Прикладная IT-конфликтология: как не убиться о стену (непонимания), решая конфликт с коллегами".

Идем, смотрим программу и регистрируемся.

Чтобы стать участником IT talk, достаточно прислать контактную информацию: имя, e-mail на адрес:  it-talk.spb@dataart.com  или позвонить по тел.: +7-812-333-4440 /ex 1224, 1225/ +7-921-772-07-65, +7-921-442-44-77

Отчеты с предыдущих "толков" можно найти у меня: IT Talk SPb-1, IT TalkSPb-2.

суббота, 17 марта 2012 г.

Краткий курс энтомологии в рамках BDD и TDD

Goblin Game: Еще раз про Automation Bias: TDD, BDD и роющие осы

Сергей Высоцкий написал интересный пост про то, можно ли целиком и полностью доверяться BDD и TDD тестам. Я не согласен с тем, что тест не может в итоге стать постоянно "зеленым". Понятно, что в процессе разработки мы будем иметь его "моргающим". Но после завершения реализации истории, он должен стать "вечно" зеленым. Иначе с этим тестом что-то не так. Другими словами, покраснение теста - это сигнал. Если в сюите есть "моргающие" тесты - это надо лечить.

вторник, 6 марта 2012 г.

Обзор VersionOne о состоянии Agile разработки

VersionOne подготовил очередной обзор состояния Agile разработки. В его составлении поучаствовало более 6000 человек.
Здесь только те цифры, которые меня заинтересовали, подробный отчет можно скачать с сайта VerionOne.
Из всех опрошенных 25% работают в компаниях, где трудятся более 500 человек. При этом более 5 лет Agile применяют в компаниях до 20 человек.

18% опрошенных практикуют Agile (лично) более 5 лет, 37% 3-5 лет. Итого 55 % - интересно. А у нас еще обсуждают, что и как... При этом почти в половине компаний процесс разработки был адаптирован к Agile практикам уже больше 2 лет назад.

Интересно, что сам факт применения Agile в компании не означает того, что все проекты работают  по Agile. В 60% компаний только половина и меньше проектов переведены на Agile.

В 77% компаний решение о внедрении Agile принималось руководством.

Какие Agile методологии используются?
























Какие Agile практики используются?














Прикольно: у 16 % Agile проекты всегда успешны.

Причины внедрения Agile
























64% отвечающих отметило, что проекты начали завершаться быстрее! У 11% время не изменилось. И только у 4% разработка замедлилась. Остальные 22% еще не закончили свои проекты.
У 57%  длина итерации до 2-х недель.

Инструменты, которые применяются



























В самом отчете есть еще интересные циферки и графики. Например есть сравнение ключевых показателей с данными по 2010 году. Кстати вот и сам обзор за тот год.

Обзор за 2012 год.

воскресенье, 4 марта 2012 г.

Тестируем свой код - книги в помощь

Полезные книжки для изучения TDD и unit-тестирования.
Тут только те, что сам читал (примечание: читаю я в основном на английском, не могу ничего сказать насчет русских переводов). Пошерстив чуток интернет, нашел отзывы и мнения и решил ими поделиться.

Классика: "Test Driven Development: By Example" Kent Beck
Отзыв на русское издание: "Экстремальное программирование. Разработка через тестирование",  все по делу написано.

Еще одна отличная книга The Art of Unit Testing Roy Osherove
Во время написания книги Рой работал в команде TypeMock. Он активно проводит тренинги на тему TDD. Сейчас правда перескочил с .Net на Ruby и в основном занят продвижением своей новой книги про лидерство в командах разработки. Но я отвлекся. Вот неплохой отзыв и еще один. Кстати, сам Рой дает свой список книг на тему разработки.

Если мы говорим о рефакторинге уже написанного кода, то тут вам в помощь Working Effectively with Legacy Code от Michael Feathers. Книгой очень удобно пользоваться, вторая ее глава  - это просто FAQ. То есть вы просто ищете свой вопрос и читаете ответ.

Chapter 6.  У меня нет времени, а менять нужно.
Chapter 7.  Изменения делаются постоянно
Chapter 8.  Как мне добавить новую фичу?
Chapter 9.  Я не могу добавить этот класс в тестовую сюиту
Chapter 10. Я не могу запускать этот метод в тестовой сюите
Chapter 11. Мне нужно сделать изменения. Какие методы я должен использовать
Chapter 12. Мне нужно сделать много изменений в одном месте. Должен ли я разорвать все зависимости во всех классах, которые используются там?
Chapter 13. Мне нужно сделать изменение, но я не знаю какие тесты писать
Chapter 14. Зависимости от библиотек меня убивают
Chapter 15. Мое приложение это сплошные API вызовы
Chapter 16. Я не до конца понимаю код для того, чтоб его менять
Chapter 17. Мое приложение не структурировано
Chapter 18. Мой тестовый код не ясен
Chapter 19. Мой проект не объектно-ориентированный. Как мне делать безопасные изменения?
Chapter 20. Этот класс очень большой, и я не хочу чтобы он становился больше
Chapter 21. Я изменяю один и тот же код в разных местах
Chapter 22. Мне нужно поменять метод-монстр, но я не могу написать тесты на него
Chapter 23. Как я узнаю, что я не ломаю ничего?
Chapter 24. Мы чуствуем себя хреново, дела не становятся лучше

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

Белая книжная полка для менеджера

Уже больше года слежу за тем, что делают два очень умных человека: Слава Панкратов и Саша Орлов. Они обладают загадочной способностью: умением зажигать мозг говоря простые и понятные слова. Более того, иногда кажется, что ты это уже знал раньше, но почему то не использовал, не применял. Сейчас они занимаются своим проектом Стратоплан, где можно найти много умного и полезного для себя, если вы руководите разработкой или планируете этим заняться :)

Недавно Саша Орлов решил заняться "мебельным" делом и начал с белой книжной полки. Причем этот интерьер мебели отдается бесплатно в хорошие руки, более того он уже заполнен полезной литературой :)
Полка весьма компактна и помещается всего в 5MB. Найти ее можно здесь.

Вообще, это посты Саши с его блога, объединенные по темам.

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

"О карьере".
Советы о том, как следует строить свою карьеру, карьеру менеджера (хотя большинство советов не только для них).
Из ценного для меня, тезисно:

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


"Общение"
"люди не любят делать то, что их заставляют делать. И люди обязательно найдут способ, как не делать того, что им не хочется" - факт, так оно и есть! Change Management - то, что должно помочь.
Интерфейсы общения: кому то проще устно, кому то письменно. Лучше всего личное общение.
Забавно про "борцов с бизнесом", сразу и не ясно, что  речь пойдет о всеми горячо любимом говнокоде :) Или как вам это: как выбить из начальства апгрейд компов? Нуждаетесь? Идем и читаем.
Про жесткость менеджера "Принимать решения – это наша работа. Иногда надо принимать жесткие решения. Но решения принимаются индивидуально по людям, нельзя всех под одну гребенку. Доверие - наше все"
И еще мно-о-ого интересного.

"Собеседования. Рекрутинг"
Советы не для тех, кто ходит по собеседованиям, а тем кто их проводит :)
Где искать, как искать, кого искать. Как проводить собеседование. "Правило 3-х хлопков" -  это прикольно :)

"Публичные выступления"
Использовал книжку в рамках подготовки к выступлению на IT talk SPb. Много полезных советов. У меня в итоге получилось имхо не очень, но косяк мой. а не книжки :). На то он и первый раз. Будем стараться дальше.

Остались пока непрочитанными: "Деньги" (эта следующая в очереди :), "Делегирование, принятие решений, отчеты", "Лидерство", "Совещания", "Как писать письма"

А теперь идем на сайт Стратоплана и получаем свою порцию знаний.

Кстати, Александра Орлова можно будет послушать на следующем IT talk SPb (ориентировочно 29 марта). Присоединяйтесь к сообществу и следите за анонсами!




четверг, 1 марта 2012 г.

Переключите тумблер или умные люди дурного не посоветуют

Навеяно интересными вопросами про TDD после вчерашнего выступления.

Uncle Bob: "Flipping the Bit"

Подробнее постараюсь перевести чуть позже, пока только это:
Как определить, что у коллеги (или у вас) ТУМБЛЕР переключен?  Если ваши ответы на вопросы ниже совпадают с приведенными - то все хорошо :)
Мантра:

  1. Сможете ли вы выполнить работу быстрее используя TDD? ДА
  2. Существуют ли какие-либо задачи, которые вы можете выполнить быстрее без TDD? НЕТ
  3. Я понимаю, что TDD может помочь в долгом проекте, а что если у вас короткая задача? Будете использовать TDD? Да, потому что TDD быстрее даже в короткой перспективе
  4. Что если времени реально не хватает, и босс стоит над душой, будете ли вы использовать TDD? ДА
  5. В любом случае? ДА
  6. Есть ли случаи, когда вам не нужно использовать TDD? НЕТ
  7. Представьте себе что вы на звездном корабле Enterprise (Star track) и осталась всего секунда до взрыва антиматерии. Все что вам нужно, чтобы избежать этого, поменять один IF. Будете ли вы использовать TDD? ДА
  8. Почему? Потому что так быстрее
  9. Даже для одного IF????? ДА, даже для единственного IF
  10. Ты хочешь сказать, что вообще нет случаев, ВОООБЩЕ, когда тебе не надо использовать TDD? Хмм, я могу не использовать TDD, но тогда времени на выполнение потребуется больше, и багов будет больше. Каких то других случаев нет.
  11. Ха, а тестирование UI? :) ну вот c UI все веселей. Короткий ответ ДА, нужно. Его можно не делать только для статичных вещей (высота шрифта, стиль, положение) - мое мнение по поводу yes, for all the dymamics

Можно ли обойтись без тестировщиков? DataArt IT talk SPb - 2

Состоялась вторая встреча DataArt IT talk SPb. Я там выступал с докладом "Можно ли обойтись без тестировщиков?"
Как получилось судить не мне, надеюсь, что участникам было интересно. Аудитория была процентов на 90 - как раз тестировщики :), говорить им о том, что они возможно не нужны было "забавно".

Вот как это было (запись не очень, но суть ясна).
ЗЫ poffm глючит, картинку не показывает. Посмотреть-послушать можно тут


Кому вдруг интересно саму запись можно взять тут, слайды тут.

PS Это выступление было первым, надо еще тренироваться :) Мое "а-а-а-а-а" и "э-э-э-э" напрягает :( Ну и вопросы надо повторять, тороплюсь ответить.

А вот мое из свеженького и чуть короче.