Обзор статей на тему Continious Integration –

Automated Testing – Agile

Подготовил – Юсупов Кайрат

Процесс разработки в Mail.Ru Group

"По мере выпуска следующих версий

программы и добавления нового функционала

нам нужно будет проверять с каждым разом

все больше и больше функций. То есть, грубо

говоря, трудозатраты будут линейно

возрастать с ростом количества функций. И

в какой-то момент руководитель окажется

перед выбором: либо начать частично

пропускать проверки старого функционала

(регрессионное тестирование), либо

постоянно увеличивать штат.“

Тех. Дир. Mail.Ru Group

Прим. * Синим цветом обозначены трудозатраты на ручное тестирование регрессионных багов.

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

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

• Тех. дир. Mail.Ru Group

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

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

В каких компаниях существует автоматическое тестирование?

• Google, Mail.ru , Yandex, Microsoft

• CodeBorne

• IBM

• BAS , NAT (Казахстанские компании )

Большинство стабильных опенсорс проектов покрываются тестами:

• Hadoop

• Apache Tomcat

• VivagraphJS

• Twitter Storm

public class HasNegationTest {

// Тест кейс 1

@Test

public void test_hasNegation_true() {

DicSentimentHighlighter sentimentHighlighter = new DicSentimentHighlighter( … );

boolean result = sentimentHighlighter.hasNegation(new String[]{" не "," хороший "} , " хороший ");

Assert.assertTrue(result);

}

// Тест кейс 2

@Test

public void test_hasNegation_false() {

DicSentimentHighlighter sentimentHighlighter = new DicSentimentHighlighter( … );

boolean result = sentimentHighlighter.hasNegation(new String[]{"хороший","хороший"} , "хороший");

Assert.assertFalse(result);

}

}

Пример модульного теста , написанного с помощью фреймворка Junit 4.1

Запускаем тесты ( кнопка Alt-F6 ), получаем отчеты по пройденным тестам

В случае с внешней зависимостью

Stub / Mock Object

Class Under Test

Connection to Database

Class Under Test

Зависимость заменяется с помощью Stub / Mock Object

Тестирование GUI с помощью фреймворка Selenide

@Testpublic void test() {

open(contextPath + "/ru/regnpv2/register");open(contextPath + "/ru/regnpv2/foreignPerson");

$(By.name("regNpVisitorList[0].lastname")).setValue("TESTACCEPT");$(By.name("regNpVisitorList[0].firstname")).setValue("TESTACCEPT");

$(By.id("next")).click();

Assert.assertTrue($(By.id("registration_start")).getText().length() > 6 );Assert.assertTrue($(By.id("registration_end")).getText().length() > 6 );

}}

В целом синтаксис кода похож на Jquery

Скрипт запускает браузер, эмулирует работу человека, вводит предопределенные данные в браузере, и контролирует работу GUI

Исключается участие человека для проверки работоспособности приложения. Тем самым снижаются трудозатраты.

Необходимые условия для покрытия кода тестами• Наличие фреймворка Junit, TestNG для Java, Jasmine, Qunit для JS

• Регулярная прогонка тестов на билд-сервере (каждый день, каждый коммит)

• Не каждый код может быть покрыт тестами

• Слабосвязанная архитектура

• Код написанный в соответствии с принципами SOLID

Принципы SOLID

• S – single responsibility

• O – open/closed principle

• L – Liskov substitution principle

• I – Interface segregation principle

• D – dependency injection

Какой код выгодно тестировать?•На этой намеренно упрощённой диаграмме показано 4 типа кода:

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

•Простой код с кучей зависимостей (участок справа внизу). ( не очень выгодно , но иногда выгодно)

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

•Обычный заурядный код, имеющий немного зависимостей (участок слева внизу).

Continuous Integration. Как оно выглядит «сейчас»

• Роль билд – сервера на данный момент выполняет - Дулат

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

Проблемы, с которыми сталкнулись во время разработки ВМП

• Развертывание функциональности без должного тестирования (практические всегда в функциональности были скрытые баги)

• Отрицательные отзывы от клиентов

• Фактически в активное тестирование были вовлечены клиенты(что не есть хорошо)

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

• Отрицательное влияние на репутацию компании и программистов

• Потерянное время , ресурсы, неоправданный стресс

Проблемы при доработке Беркут

• Документации нет

• Никто не знает , как работает код для миграции данных

• Автотестов нет ( вносить изменения необходимо очень осторожно)

• Долго кропотливо и разбираться, что делает каждая строчка кода

• Нет гарантии безопасности изменения кода

• Стоить отметить, что тесты могут использоваться как документация , т.к. тесты описывают спецификацию классов , функций и т.п.

Continious Integration. Как «должно быть»Continuous Integration (далее CI) — это практика разработки программного обеспечения, в которой члены команды проводят интеграцию не реже чем раз в день. Результаты интеграции проверяются автоматически, используя автотесты и статический анализ кода.

Преимущества CI

• Использование CI позволяет вовремя отслеживать ошибки интеграции

• Сделать систему и процесс разработки более «прозрачными» для всех участников команды

• CI избавляет от рутинных операция по сборке продукта, запуску тестов, повышает качество продукта, включает в себя профит от написания тестов.

• Автоматическое оповещение участников команды о наличии проблемы (бага, ошибки, не развертывается проект) в проекте

Необходимые условия для развертывания CI

• Регулярное автоматическое выполнение билдов проекта

• Достаточно высокое покрытие проекта тестами

• Обратная связь билд-сервера с разработчиками проекта (разработчик должен оповещаться о наличии проблемы, и именно тот разработчик внесший изменение , повлиявшее на билд)

• Существуют следующие популярные механизмы осуществления обратной связи:

• SMS

• browser plug-in

• светофор сборок

• звуковое оповещение

• email

Примеры отчетности

Горизонтальная ось - билды

Вертикальная ось – тест кейсы

Синим цветом отмечены пройденные тесты.

Красным цветом отмечены непройденные тесты(ошибки).

Примеры отчетности – процесс сборки

Как Google тестируется ПО“идея заключается не в создании тестов как таковых, а в ускорении разработки.”

В Google существуют три роли тестеров:

SWE - основные разработчики, которые работают над функционалом. На них лежит разборка кода (code review), TDD, Unit тестирование и приемочные испытания. Они так же ответственны за качество каждого участка кода. Это важно. Тестеры не отвечают за качество. SWE не может написать немного кода, а потом сказать тестеру, попробуй улучшить этот код. Это его собственная работа.

SET — занимаются разработкой среды для тестирования. Они не пишут непосредственно тест кейсы. Они создают инфраструктуру для их создания. Они выпускают фрэймворки, пишут утилиты автоматизирующие рутину проверок. Они создают автоматизированные процедуры.

Процесс разработки Google plus занял 100 дней.

Каждый день собирается новый релиз Google Chrome.

You Can't be Agile Without Automated Unit Testing• Тезис вытекающий из предыдущих пунктов:

• Невозможно внедрить Agile/Scrum методологию без уделения внимания современными инженерным практикам( код ревью , автоматическое тестирование, непрерывная интеграция).

• Agile projects assume that test planning, test creation, and test execution take place throughout a project's lifecycle. So the need for unit testing (and especially automated unit testing) can't be ignored and should be considered as a key responsibility of the entire team—not just the software developers

Developers have known for decades that the further into a project timeline a bug gets discovered from its insertion point, the more costly it is to fix. When a developer finds a bug, it can sometimes take minutes to fix. If it slips through testing and finds its way to the customer, figure 1 shows that mitigation can be exponentially more expensive to fix.

Agile methodologies take working software and combine it with early feedback. To give the developers confidence that their code works, unit testing gives the fastest available quality feedback.

The earlier defects are found, the cheaper they are to fix.

Ссылки

• 1. Тестирование в Mail.ru Group:

• http://habrahabr.ru/company/mailru/blog/165877/

• 2. Как перестать беспокоиться и начать работать:

• http://habrahabr.ru/company/skbkontur/blog/128427/

• 3. Continuous Integration. Путь обеспечения надежности и доверия к системе

• http://habrahabr.ru/post/219891/

• 4. Как Google тестирует ПО

• http://habrahabr.ru/post/135776/

• 5. Компания Agitar зарабатывает тем что разрабатывает автоматическое тестирование для заказчиков

• http://www.agitar.com/solutions/why_unit_testing.html

• 6. You Can't be Agile Without Automated Unit Testing

• http://www.stickyminds.com/better-software-magazine-article/you-cant-be-agile-without-automated-unit-testing

• 7 Полное регрессионное тестирование за 4 часа

• http://scrumtrek.ru/stories/view/13