среда, 29 апреля 2015 г.

13 вопросов для выбора инструмента автоматизации тестирования (проверок?)

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

Кстати, сейчас Болтоном и Бахом активно продавливается тема, что это не автоматические тесты, а автоматические проверки (testing vs checking). Но это тема отдельного поста, холиварить будем там.

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

1. Я хочу посмотреть список тестов, какие проверки ими делаются и какая функциональность продукта проверяется. Можно ли это сделать с рабочего места, например Product Manager-а или меня как руководителя разработки, без установки дополнительного ПО?

2. Возможно ли написание одного теста в виде пользовательской истории из последовательных шагов (проверок) пользователя выполняемых на разных машинах.

3. У меня есть повторяющиеся действия, которые нужно делать в нескольких тестах – могу ли я сделать «библиотеку действий» и использовать ее при написании тестов.

4. Можно ли одни и те же тесты запускать с разными настройками, на разных окружениях?

5. Как посмотреть результаты тестов без установленного дополнительно ПО? Если ли возможность присылать их по почте? Если да, то откроется ли это в осязаемом виде и что будет, если это результат 100, 500, 1000 тестов.

6. Как хранится история запусков? Можно ли контролировать время выполнения тестов для профилирования и сравнивать время запуска с предыдущими.

7. Если тест красный – то как разбираться? Есть ли возможность привязки логов продукта к тестам, сборки нужных логов как артефактов.

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

9. Какая система хранения исходников тестов и формат настроек (если они есть). Есть ли возможность привязки тестов к исходниками продукта (чтобы было понимание того, какие тесты на каких исходниках работают).

10. Можно ли менять данные для тестов автоматически (снаружи). Например для проверки версии продукта – чтобы каждый раз руками не менять в тестах. То есть, возможно ли генерить/менять тесты (или данные для них) автоматически.

11. Можно ли в инструменте использовать компоненты продукты (исходный код, бинарники) для тестирования

12. Существует ли возможность интеграции в системы CI, если да, то какие и что можно получить.

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

PS Число 13 случайно получилось - просто выписал все из головы, а получилось 13. Можно конечно продолжить и действительно есть чем, но пусть будет так. Символично...

понедельник, 27 апреля 2015 г.

Сборная солянка видеодокладов для самообразования на разную тематику - Выпуск 4

В этот раз не совсем солянка, скорее сборник :)

В своем отчете о PiterPy#2 я упоминал, что познакомился там с Григорием Петровым.
Порыв интернеты, нашел несколько интересных видео его докладов.

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

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

Зачем выступать на конференциях
Кроме вопроса "зачем выступать", Гриша отвечает на вопросы как готовится, на что обратить внимание в презентации, а также зачем ходить на доклады :)

Есть еще доклады (в т.ч. про комментирование исходников и то, как их хранить)

Интервью Гриши на конференции PiterPy "Чем похожи программирование и алхимия?"

пятница, 17 апреля 2015 г.

Software-Engineering Myth Busters (покрытие кода тестами, TDD, организация и распределенные команды)

Наткнулся недавно на подборку интересных исследований проведенных Empirical Software Engineering and Measurement Research Group.

Товарищи на примере деятельности команд разработки Microsoft попытались получить хоть какие то цифры отражающие влияние различных инженерных практик и процессов, например TDD на качество получаемых продуктов.

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

Влияние покрытия кода тестами на качество
Покрытие кода рассчитывается как процент (отношение) строчек кода, которые вызываются при запускаемых тестах к их общему количеству.
Казалось бы логичным считать, что чем больше покрытие - тем лучше качество. Но результаты показали, что не все так просто (кто бы мог подумать).
Одна метрика не может характеризовать качество для любых продуктов. Процент покрытия кода сам по себе ничего не говорит, если не учитывать сложность кода и частоту его использования.
Если 99% кода протестировано, но оставшийся 1% кода постоянно используется, то от 99% толку мало. Также влияет сложность кода: сложный код сложнее тестировать, и добиваться высокого процента покрытия.
Итого: важно получить большое покрытие для сложного и часто используемого кода, чем "просто некий" процент покрытия.
Еще интересная статья про покрытие: How to Misuse Code Coverage
И еще про TDD и покрытие

Влияние TDD на качество
В исследовании рассматривались результаты команды практикующих TDD и не использующих эту практику, при этом подчиняющихся одному менеджеру (видимо, чтобы убрать наводку менеджерской активности на результаты). Эти команды разрабатывают Windows, Visual Studio и MSN (в самом исследовании есть еще результаты команд IBM).
Получились такие цифры: команды с TDD писали на 60-90% лучше, чем те которые игнорировали эту практику. Но, при этом время на разработку увеличивалось на 15-30%.
Рекомендую глянуть само исследование подробней. Там приведены исходные данные в виде размера команд разработки, их опыта, применяемых языков программирования и сроков разработки.
Итог получился в виде такой табличке

Использование проверок в коде (assertions) и как оно помогает
Еще одно интересное исследование. В качестве подопытных выступили две команды двух разных компонентов Visual Studio. Тут подробно расписывать не буду, дока не маленькая. Вывод закономерен: больше ассертов - меньше багов. Но интересно, что при внедрении этой практики настойчиво рекомендуется не вводить метрик в виде отношения количества ассертов к количеству строк. Разработчик должен "чувствовать" и осознавать необходимость использования таких проверок. Кстати, статический анализ тоже поможет.

Следующие два исследования анализировали влияние организационной структуры и распределенности команды на качество кода
Кроме влияния традиционных метрик кода (code churn, code complexity, code dependencies), хочется понимать, а как на итоговый результат может повлиять организационная структура команд(ы) разрабатывающей продукт. Это исследование описывает влияние всех этих метрик. Организационные метрики получились достаточно запутанными, и я в них пока не въехал :)

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

В общем, кому охота прогрузиться цифрами на выходных - вам сюда.

воскресенье, 12 апреля 2015 г.

Тестируем с помощью Fitnesse+PowerSlim. Часть 5. Пример

Часть 1. Введение 
Часть 2. База 
Часть 3. Advanced
Часть 4. Демо FitNesse + Jenkins
Часть 5. Пример трансформации PowerShell скрипта в тест
Плагин для sublime, который подсвечивает синтаксис теста на Fitnesse+PowerSlim

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

Итак, "мы прочитали твои посты, позапускали примеры, дальше то что? С чего начать?"

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

В Hyper-V PowerShell API есть такие cmdlet'ы: New-VM, Get-VM, Remove-VM. Давайте попробуем проверить, что мы можем ими пользоваться. Ситуация выглядит немного синтетической, но представьте, что есть продукт, который стоит внутри Hyper-V и расширяет модель авторизации этой платформы виртуализации. Такой продукт даже в природе существует  (vGate for Hyper-V) :)

Если опустить за рамки примера установку и настройку vGate, то хочется проверить, что пользователь может создать виртуальную машину и удалить ее.

Для этого можно использовать например такой PowerShell скрипт (проверки условны, но имеют право на жизнь):


New-VM -Name newVM -ComputerName 192.168.2.21 -MemoryStartupBytes 32MB -NoVHD
$vm = Get-VM -Name newVm -ComputerName 192.168.2.21 #получили созданную VM
$vm.State -eq "Off" #проверили что она выключена
Remove-VM -VM $vm -Force #удалили
$vmX = Get-VM -Name newVm -ComputerName 192.168.2.21 #опять пробуем получить
$vmX -eq $null #проверяем что не смогли

Собственно проверок (assert'ов) то здесь и нет, поэтому давайте их сделаем на FitNesse+powerslim.

Как видно, каждая строчка PowerShell скрипта превратилась в отдельную команду скрипта FitNesse. Так удобнее для удобства чтения и проверок, хотя никто не запрещает выносить несколько PowerShell команд в одну строку с разделением через ';' (а, например, при использовании PowerShell функций этот способ просто необходим)
Там где нужно просто выполнить PowerShell команду - мы используем eval, там где нужно проверить и сравнить, используем комбинацию check и eval.

Каждая строчка скрипта FitNesse отправляется на указанный в команде script powerslim-сервер, запущенный на удаленной машине (у нас 192.168.1.31), и там, с помощью команды Invoke-Expression выполняется. (Для тех кто любит поковыряться в кишочках: посмотрите скрипт splim.ps1, там используется Invoke-Expression alias: iex). 

Вот так вот мы получили первый тест, примитивный, но работающий.

Теперь про полезные хитрости (возможно, это не всегда очевидно). 
Результат возвращаемый в переменных PowerShell (в нашем случае $vm, $vmX) будет "жить" все время пока запущен powerslim-сервер, который выполнял команду. Другими словами, мы можем разделить выполнение команд eval и check в разные script'ы и все будет работать как и раньше. Более того, между этими командами можно выполнять команды на других powerslim-серверах, если нам это нужно по сценарию проверок (в пример ниже - 192.168.2.10):


Тут видно, что мы используем переменную $vm в другом вызове script на 192.168.1.31, так как знаем, что она там еще "живет".

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

А вот как выглядит результат выполнения этого скрипта в консоли powerslim сервера: 

Тут видны выполняемые команды, результат их выполнения и ошибки (красным). Например, в нашем случае, мы не смогли получить виртуальную машину после ее удаления (второй Get-VM) и PowerShell cmdlet вернул нам описание ошибки. Объект $vmX при этом равен $null.

Подобного рода вывод в консоль powerslim-сервера, при его редиректе в файл, помогает разбираться в возникших проблемах.

Обратите внимание! Время выполнения одного теста по умолчанию ограничено 10 сек. Для увеличения необходимо задать нужно значение свойству slim.timeout в файле plugins.properties лежащему рядом в запускаемым fitnesse-standalone.jar. Задается как slim.timeout = 100, где 100 новое значение тайм-аута в секундах).

Надеюсь, эта статья прояснила некоторые моменты и поможет вам в освоении FitNesse+PowerSlim.

Приведенный выше пример очень далек от "production"-тестов: например адреса серверов, имя виртуальной машины лучше задавать через макросы. Повторяющиеся действия, например Get-VM, выносить в сценарии. Но это уже другая история.

И помните, "Дорогу осилит идущий" (с) :)
Удачи!

вторник, 7 апреля 2015 г.

Прямо с моей головы писано: "The Rise and Fall of Unit Testing"

taw's blog: The Rise and Fall of Unit Testing

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

Unit-тесты не спасают нас ни от "лапше-кода", ни от плохого дизайна, ни от нерабочего продукта. Но они помогают помогают этого избегать - это факт. Просто везде надо знать меру. А включение головы никто не отменял.

И про mock-и я тоже писал

четверг, 2 апреля 2015 г.

Сборная солянка видеодокладов для самообразования на разную тематику - Выпуск 3

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

Видео всего два и начну с "Jira против PivotalTracker" (а то после анализа второго, до него не доберется никто). А оно интересное. Живо, динамично. Мне больше понравился Pivotal, наверно потому что я его использовал когда то. Защитник Pivotal'a креативен :)

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

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

Идем дальше. (Осторожно, холивар!)
Почему то, TDD многие рассматривают только как юнит-тесты и ничто другое. Мне кажется чаще проще отталкиваться от итогового результата и попробовать посмотреть на тесты в том числе и уровнем выше.

Поясню: берем классический пример TDD - калькулятор. Это приложение с заданной функциональностью. Чаще всего, реализованное в одном классе (и тут первая ловушка). Дальше в примерах мы начинаем писать класс отталкиваясь от того, что нам нужно в калькуляторе (повторюсь не в классе, а калькуляторе). Получается, что пишем приемочные (функциональные) тесты и то, что он работает на уровне класса (юнита) - это просто для облегчения донесения информации.

Аналогично с примером Андрея (кстати, классная игра). Он пишет приложение в котором вся логика внутри одного класса. Понятно, что все приложение будет работать и базой данных, и логировать и тп "обвязкой", но логика приложения в одном классе. Мы тестируем всю логику приложения через один класс и опять, то что наши тесты юнит - это просто потому, что больше ничего у нас еще и нет (да и не будет).
В обычной жизни, чаще всего, вся "обвязка" уже есть и написать тест уровнем выше (выходя за рамки класса), используя подход "тест вперед" проще, чем мокировать все, что движется используется и писать классический юнит-тест. Ведь, согласитесь, в реальности, у нас все гораздо запутанней и сложнее, чем один класс. И я не согласен с тем, что такие тесты всегда долго работают и что это могут быть только UI-тесты. И приложение получается сразу можно попробовать в реале, а не на классах смотреть. Что то похожее на мои мысли тут.

Допускаю, что мой подход неканоничен. И вики выделяет Acceptance TDD от TDD. Но поверьте, он тоже работает и чаще проще понимается разработчиками. Если у вас проблемы с внедрением тестов - попробуйте.
Пожалуй закончу тут про юнит-тесты. Подумалось, что надо отдельную статью писать. Есть еще много мыслей отличающихся от канонов, а то этот пост совсем еретическим получится и до конца никто не дочитает :)

Вернемся к докладу.
  • Отсыл к Чаку Норису и охоте vs убийство - отлично :)
  • Тестировщики не нужны!? Обожаю эту тему :)
  • Узнал про Gradle. Андрей его использует для запуска тестов в разном порядке. Есть и C++ версия, надо посмотреть, что за зверь
  • Мутационное тестирование: меняем код - смотрим какие тесты отвалились. Отличный прием, мы им пользовались лет 6 назад (ужас, как давно уже).
  • 20 минут ответов-вопросов после почти 2-х часового доклада. Слушателям понравилось, думаю, если бы Андрею не надо было бежать на автобус, его бы еще долго не отпускали
Резюмируя (тут то, что срезонировало с моим понимаем проблемы и я под этим подписываюсь):
  • Тесты заставляют разработчика думать
  • Разработчики должны иметь возможность запускать тесты на своем компе
  • Тесты решают проблему 95% багов, остальные 5%  мы чиним быстро, если в них втыкаются.
  • Для хороших тестов надо уметь переключать mindset с "разработчик" на "тестировщик". Это разные типы мышления.

среда, 1 апреля 2015 г.

Изучаем Python с нуля

(c)
Иногда коллеги спрашивают. Решил все свои рекомендации в одно место сложить.

Ссылки для самообразования:
Еще немного ссылок на Python для детей

PS буду признателен, если посоветуете еще интересных ресурсов.