Первый опыт внедрения TDD

Один из моих проектов - программа моделирования кристаллизации в бесконечной системе жестких сфер.

Небольшой проект, но сложные алгоритмы. Большие функции со сложной логикой. Огромное число расчетов - часто проблемы не видны при "тестировании" элементарных конфигураций.

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

"у нас нет времени писать юнит тесты, надо делать новый функционал"

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

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

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

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

Или не приступаем к рефакторингу кода тестов, по принципу "работает - не трогай". А работает оно медленно и не эффективно, мы знаем, но ничего с этим не делаем.

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

http://www.fzdschool.com/programs_design_cinema.html

Качество

    Качество это не контроль и гарантии, не информация.

    Когда перед нами качественная вещь, вот мы вертим ее в руках. О чем мы думаем и что представляем?

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

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


    И, кстати, сегодня я полюбил mongoDB.
    Отличный элементарный интерфейс и серьёзные возможности.

Selenium тесты на linux server

Часто есть необходимость запускать автоматизированные тесты для веб интерфейсов на Linux сервере без графической оболочки (например, на сервере непрерывной интеграции)

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

Краткая инструкция (на случай недоступности ссылки, в такие времена живём, на днях https://pypi.python.org лежал)

1. Устанавливаем все необходимые пакеты:

apt-get -y install xvfb x11-xkb-utils xfonts-100dpi \

                           xfonts-75dpi xfonts-scalable \

                           xfonts-cyrillic xserver-xorg-core

2. Настраиваем

Xvfb -fp /usr/share/fonts/X11/misc/ :22 -screen 0 1024x768x16 2>&1 

export DISPLAY=:22

3. Готово, если запустить firefox + webdriver, то браузер запускается в виртуальном рабочем столе.

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

Python + BDD = Behave?

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

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

Давайте напишем простую историю использования в нотации Gherkin.

   Feature: Administrative web interface

     Scenario: Login
          When user opens browser and navigates on the page "site.com"
              and user "admin" enters login and password in the login form 
              and user clicks "Login" 
            Then user should see the administrative web interface 

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

BDD. Тестирование на основе историй использования

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

Такими дополнительными требованиями можно назвать, например:
1. Скорость разработки и отладки тестов.
        Такие тесты необходимы как можно раньше, их приоритет выше остальных автоматизированных тестов. Запуск тестов после каждого нового изменения в продукте позволяет быстро реагировать на появление проблем и убедиться, что новая версия проходит хотя бы приемочное тестирование.
2. Легкость взаимодействия с системой непрерывной интеграцией и другими компонентами, задействованными на проекте.
        Необходима простота запуска тестов и анализа результатов. Взаимодействие с популярными фреймворками и плагинами и работа с привычными форматами файлов могут существенно облегчить жизнь и сохранить ваше время.
3. Стабильность тестов.
        Это требование применимо к любым тестам, но к приёмочным оно особенно строго оценивается. Автоматизированные приёмочные тесты должны сообщать о проблемах, которые действительно есть на проекте, у вас не будет времени анализировать результаты после каждого запуска тестов и проверять все упавшие тесты. Просто потому что они запускаются в час ночи, когда вы спите.
        Одновременно с этим мы должны помнить, что еще больше трудностей возникнет, если автоматизированные тесты будут ложно-положительными, потому что в этом случае мы теряем сразу все преимущества непрерывной интеграции, снова тратим время на обнаружение проблемы и поиска причин ее возникновения.

Selenium +

Автоматизированное тестирование это очень высокотехнологичный процесс, требующий времени высокооплачиваемых специалистов.

Сегодня мы говорим о Selenium и о том, как разрабатываются автоматизированные тесты с использованием таких языков программирования, как Java и Python.

Когда я экспериментировал с Selenium Web Driver на питоне, передо мной явно вставала проблема нечитаемого кода автоматических тестов. Я экспериментировал, писал простые тесты, но явно видел, что это не то, что я хотел бы использовать в своей работе.

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

А потом я посетил сайт pyvideo.org, с которого позаимствовал это видео с выступлением одного из экспертов Selenium

Что интересно тестировщикам?

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

Вы можете оставлять комментарии, у вас точно есть хорошие идеи на этот счёт.