Напочитать: Автоматизация тестирования: Disruptor

Два доклада про тестирование в LMAX  вдохновили.

Потому и  Disruptor.

1. Адовый рассказ про то как делать Continuous Delivery на биржеквых проектах от LMAX.

2. Продолжение темы, только более философское, но тоже от выходца из LMAX.

3. Про автоматизированное тестирование CRIU и суровый линуксовый жесткач
4.  Подборка статей от пользователя @irony_iron на хабре про автоматизацию очень сурового системного тестирования - антивирусы и перезагрузки, инсталляторы, автологины в винду. Очень хардкорно!
5. XPath, JsonPath... теперь GPath - очередная path-нотация для JSON. Но в RestAssured.
6. Про то как скалировать тестирование на Robot Framework под Docker - презентация, видео, код
7. Про Jenkins Workflow - с картинками и примерами.
8. Log4J теперь говорят не тормозит.
9. Almost 16% of our tests have some level of flakiness associated with them! This is a staggering number; it means that more than 1 in 7 of the tests written by our world-class engineers occasionally fail in a way not caused by changes to the code or tests - и другие интересности от Google как они борятся с  flaky tests. Спойлер: все банально!!!
10. Про автоматизацию тестирования c мобильными устройствами , но не теми про которые вы подумали.
11. Маленький хак для тех кто использует Spring Test.
12. Гойко Аджич про то как сократить издержки на большие тестовые наборы - на самом деле тэги по функциональности, отсутствие зависимостей при запуске тестов, выделение утилитарного слоя кода, хорошие имена для тестов.
13. Про то как взять и упороться функциональщиной из Java8 в Selenium-тестах - с примерами и картинками.
14. Очень полезная вещь - Jenkins-у можно править конфиги удаленно, сам несколько раз пользовался.
15. PowerShell и Jenkins.
16. Github выпустил Spectron 3.0 - тестовый фреймворк для своего поделия Electron (Desktop приложения на node.js) написанный поверх  CrhomeDriver и WebDriverIO.
17. Maven + JUnit + интегрционные тесты  и все как мы любим.

Напочитать: про тестирование в 7 строчек

1. О попытках  придать ума процессу Fault-Injection Testing в Netflix.

2. О том что такое SecurityManager в Java и как им можно повалить половину приложения. Про повалить не написано, но вы уж сами дофантазируете, да ?

3. Реализация expected exceptions в JUnit никогда не вдохновляла, но вот тут покусились даже на нее.  И чем !!! Лямбдами! Кстати да, JUnit5 (в оригинале JUnit Lambda) уже вышел в aplha-версии и лежит уже в Maven Central

4. Google выпустил EarlGrey для автоматизации тестирования IOS.

5. О том как бывает сплит-тестирование на практике от товарищей из Badoo и что для этого нужно сделать. Молодцы, чо.

6. headless-браузер на чистой джаве может быть не только убогим html-unit - есть еще и jBrowserDriver.

7. Ну и в качестве вишенки на тортик - Сергей Мартыненко о стратегии тестирования:
Подготовка стратегии тест-ния под высокориско-ный, высокодох-ный прое from Vlad Orlikov on Vimeo.

Напочитать: Тестовый инструментарий антигуманитария

1. Хороший дайджест для тестировщиков со всем XML-технологиями.

2. Объяснение на пальцах что такое CQRS и Event Sourcing.

3. Долгий но полезный рассказ о том как уничтожать плохие продуктовые идеи. Если вы тестировщик и не понимаете зачем вам это - слушайте старших.

4. Amazon запускает свой device cloud для тестирования Android и своей Fire OS.

5. Старый рассказ с Google Tech Talks о том как Dependency Injection/ Inversion of Control влияет на тестируемость.

6. Ребята из Яндекса рассказали о том как они балансируют Selenium Grid-ы. То что Selenium Grid хреново масштабируется известно давно, нам тоже пришлось сталкиваться с этой проблемой. Может быть когда-нибудь и мы расскажем о нашем подходе.

7. Twitter опубликовал свою Diffy - утилиту для back-to-back тестирования сервисов.

8. На Indiegogo успешно прошла краудфаундинговая компания по сбору средств на создание JUnit Lambda - следующей версии JUnit. Бюджет собрали аж дважды (216% если быть точным), есть надежда что скоро процесс пойдет, а пока можно почитать вики проекта на GitHub. Ребят проблема настолько актуальна для всех ?  Поделитесь болью в комментах.

9. ExtentReports - Очередная библиотечка для генерации репортов от автотестов. Кстати выглядит на первый взгляд весьма сексуально. Код тут.

10. Про кучу возможностей для тестирования и fault-injection testing в докладе Игоря Сухорукова, который на самом деле про аспекты.

11. О том как тестируют качество звука в WebRTC. Отличный и довольно простой пример привнесенной testability.

12. Как всегда, красочно и про самую  писечку - он иначе не умеет - Алексей Лупан про регрессионное тестирование.

13. Что не является тестируемым кодом - с примерами.

14. Как писать юнит-тесты на многопоточный код.

15. Facebook запилил WebDriverAgent - A WebDriver server for iOS that runs inside the Simulator. Ну вы поняли - скоро будут гриды на архитектуре WebDriver-а.

16. Про тестирование безопасности API раз, два, три.

Напочитать : Выпуск внезапной весны

1. Весьма странная смесь, но тем не менее - кому-то может оказаться полезной. Jodd.

2. Удивляетесь что вышла новая версия либы в maven central а вы не в курсе?  Я тоже. Но мечты стали реальностью - artifact listener.
3. Сравнительная таблица Dropwizard vs. Spring или что вам большу подходит для микросервисов. Dropwizard конечно же :).
4. Отличный и короткий гид по заголовкам кэширования  в HTTP. Люблю такие,
5. RoboVM - это чтобы на Java под iOS. Правда платно, и наверное даже стремно.
6. Про стратегии герметизации, mock-анья и за-stub-ливания для тестирования Android приложений от гугла.
7. Maven теперь может не только XML. Хипстеры, хуле.
8. Старинное от Влада Балина

Создать свою структуру и пришлепать ее сбоку может любой дурак. Квалифицированный инженер-программист (с упором на первом слове, не путать с "программером") умеет проводить анализ "чужой" подсистемы, восстановит мысль и идею автора, сможет мысль автора развить, продолжить ее, и эффективно решить свою задачу в рамках чужого подхода к проблеме. Все это - работая с кодом. Это отличительная компетенция архитектора, высший уровень инженерного мастерства. И это имеет весьма отдаленное отношение к "рефакторингу". 
Толу на самом деле было все равно, есть документация или нет. В совершенстве владея reverse engineering, он в уме потрясающе легко умел переходить от кода к архитектуре, и наоборот. В результате, проектируя, он всегда детально представлял, в какой код превратятся его мысли, и поэтому был способен быстро прокручивать в голове огромное количество вариантов, отбрасывая "плохие". В его понимании, архитектор, не умеющий читать чужой код с "листа", и не пишущий своего - подобен инвалиду, пытающемуся бегать на костылях. Он довольно быстро закончит очень плохим архитектором - вопрос нескольких лет.
Второй важный аспект этой философии - понимание того, что код пишется в первую очередь для человека, и только во вторую - для компьютера. Это приводит нас к идеям, близким по духу к literate programming, за которое ратует Кнут. Как может человек, который не в состоянии внятно выразить свою мысль на неформальном, знакомом ему с детства естественном языке, выразить эту же мысль понятным образом на существенно более формальном языке программирования? Но это уже другая история.

9. Куча статеек про то как правильно пользоваться JUnit, но я обратил внимание только на пару и те про Rule-ы - первая и вторая. И еще вот тут хоршее-архитектурное про JUnit.
10. Одна из десятков тысяч статей про няшки в Guava - UnsignedInts, CHarMatcher, MurmurHash, InternetDomainName,ClassPath utils.
11. Google заопенсорсил свой внутренний билдтул bazel.io. Найдите 10 отличий от buck в исполнении Facebook, который пилит бывший инженер Google :D Пожалуй разрожусь-ка я статейкой про Not Invented Here синдром.

Встраиваем тесты в приложение или интеграционное тестирование с хохломой и гимназистками

Преамбула.

Как-то летом один персонаж сказал, что он собирается встроить тесты внутрь самого приложения. Тогда я молча поржал про себя.
Спустя 3 месяца на Agile Testing Days я побывал на докладе, где рассказывалось о том что Runtastic делал так для того чтобы выявить багу на устройствах пользователей.

The developers decided to build a unit test into the app where they could check the result of the device’s calculation for a well-known distance between two coordinates.

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

Амбула.

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

Если вам не достаточно кейса Runtastic приведенного выше, то отвечу.
Если у вас все хорошо, production вам подконтролен, конфигурация зафиксирована и проблем нет - оно вам не нужно.
Но не у всех и не всегда оно так.
Примеры когда оно не так:

1.  Вы разрабатываете что-то что будет ставится в непонятное окружение или контейнер и вам нужно понимать что окружение соответствует.
2. Окружение в которое вы ставите свое поделие может динамически меняться и об этом тоже было бы неплохо знать.

В общем и целом оба вопроса выше сводятся к вопросу о доверии к reference implementation чего-то что вам дают снаружи ( в случае с Runtastic таким reference implementation-ом было API  по работе с GPS видимо).
В зависимости от того насколько большому куску мы не доверяем может захотеться написать как Unit-тест, так и интеграционный.
Рассмотрим оба случая :).
Естественно я буду рассматривать это все на Java потому что режиссер так видит (с)  мне так нравится, но все показанное ниже также справедливо и реализуемо для всех остальных промышленных языков программирования.

Покажи мне свой код.

Да детка, обнажи свой свежий, горячий код и я сделаю тебе ревью! 
Давай делать это бесстыдно! Давай делать это на гитхабе!

Код собственно на гитхабе.
Клонируем, в консоли запускаем mvn exec:java, видим такое.

Дальше идем в браузере идем на урлы:
http://127.0.0.1:8080/runUnitTests - для запуска Unit тестов

Видим такое


http://127.0.0.1:8080/runIntegrationTests - для запуска интеграционных тестов.

Видим такое
Посмотреть в код под капотом (кому и если будет интересно) вы сможете сами.

Мысли вслух.

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

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

Второй интересный момент который я нашел именно в такой реализации заключается в том, что подключение реальных кусков бизнес-логики к интеграционным тестам может помочь ловить баги, которые воспроизводятся только в определенных условиях.
Минусы тоже имеются - если в ваши слои бизнес-логики можно вносить изменения в runtime, то запуск таких  интеграционных тестов может положить вам ваш production.
Еще более просто и конкретно - такая штука может положить нафиг весь ваш prod и данные.
И да - подобного рода трюки не предусматривают никакой защиты от этого кроме code review.


Третье - такой подход тянет за собой все зависимости необходимые для тестов в основной продукт - то есть всякие junit, mockito, hamcrest. Ну и код тестов конечно.
Избежать этого можно - в своем примере я развел это через профили сборки maven.
Единственная корявость которая есть - приходится указывать значение свойства по умолчанию для исключаемых при компиляции пакетов.

При обычной сборке (mvn clean package) с такой настройкой содержимое архива будет выглядеть так.

А при релизной (mvn clean package -P release) вот так

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


P.S. Как и обещал.
Хохлома.
Гимназистки.

Напочитать: 10 заповедей

1. Встала проблема тестирования с использованием системных свойств Java. Нашлась отличная библиотека.
2. Иногда процессы покупки лицензий затягиваются, а жить как-то надо. Выход есть. По крайней мере для VmWare ESXi.
3. Пишем свой простенький Java Agent. Для чего это нужно ?  Ну например потестить как себя ведет система при изменении времени, или остановить это время насовсем.
4. Кроссплатформенное тестирование Android и iOS приложений - на такую задачу пока замахнулся только Sauce Labs со своим Appium. Правда еще одни ребята решили что сделать это можно на Jython и Sikuli. Посмотреть что получилось можно тут и тут.
5. Длинный, но живой рассказ от J.B.Rainsberger про то что интегрированные тесты есмь гавно не есть гут. Рассказ с конференции DevConFu которая проходила в Риге  в прошлом году в ноябре и в этом году тоже будет.


J.B. Rainsberger - Integrated Tests Are A Scam from devtraining on Vimeo.

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

6. Еще один добрый (без шуток) человек выложил набор видеоуроков в сеть. Все что вам нужно приложить  - это (как обычно самое сложное) силу воли и самодисциплину.

7. Графики и дэшборды становятся частью повседневной жини IT-компаний. Про графит наверное уже слышали многие если не все, а вот и подборочка инструментов для построения дэшбордов на его основе.

8. Как взять и обосраться с микросервисами - правдиво зато!

9. Контейнеры грядут на смену виртуальным машинам в продакшене. В связи с чем у людей возникает вопрос "А так ли хороши контейнеры???" на который просто обязаны были ответить маркетологи из IBM. Большой отчет для тех кому интересны детали и выжимка для всех остальных.

10. Отличный наброс от качественного набрасывателя

But a lot of everyday programmer’s activities fall into the same category. Dependency management, for example. If you spent a day setting up compilation workflow and getting dependencies right, it’s not a day of good work. It’s a day lost. You haven’t created new value, you haven’t enabled a single person to do anything that wasn’t possible before. You were satisfying other programs’ demands. Even the fact that this activity has its own name indicates there’s something wrong with it. I hope there isn’t an actual job title like “Dependency management engineer”, is there? I probably don’t want to know.

На этом все. Блог уходит в отпуск до середины сентября.

Автоматизация тестирования: Как падать более элегантно

Если нельзя, но очень хочется - то можно.

Решил написать про отложенные ассерты.
Эта техника появилась у нас более года назад.
Аналогичная техника есть в TestNG - там она называется SoftAssert.
Прочитать про нее можно вот тут и тут.
От TestNG мы отказались и их SoftAssert-ами никогда не пользовались, а вот техника прижилась.
Мне очень не нравится слово SoftAssert - ассерт не может быть мягким.
Мы называем это Delayed Assert - ассерт все равно случится и если условие не выполнено тест упадет, но сделает это позже, пройдя через еще пару точек проверки (может быть :)).

Зачем оно надо? 

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

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

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

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

Как оно работает? 

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

В натуре

Проект выложен на гитхабе.
https://github.com/kronar/delayed-asserts

Gist c примером того как оно падает.
https://gist.github.com/392a0f488127f811d7a2.git

Интеграционное тестирование с JUnit

Преамбула
Делаю доклад+презентацию про автоматизацию функционального тестирования на Java.

Амбула
Имею честь наблюдать некоторую массу мнений насчет того, что вот есть TestNG, который как бы наше все.
И все в нем есть и всем он хорош. И даже DI/IoC поддерживает с Google Guice.
А JUnit.... ну он так, для юнит-тестирования и только. Написан программистами для программистов.

И не соглашусь с этим всем безобразием.
Туго скрутив документацию по JUnit в сигару и выкурив ее я за полдня сваял Proof of Concept
того что DI/IoC тоже может работать в JUnit.

Ну а если покурить сорсы TestNG там можно обнаружить много всего жирного для такого кодового фашиста как я.
Например такое