Quality Assurance Tools: Паранойя в квадрате или как проверить собственный код на вшивость.

Преамбула

В пылу работы, особенно если могут отвлекать, люди могут забывать очевидные вещи.
Не потому что они плохие или некомпетентные, не потому что мало времени,а просто потому что вот забыли и всего делов.
Особенно больно становится когда твой код на Java, а люди забыли про определение методов equals и hashCode у объектов представляющих собой сущности в домене. toString конечно еще, но с ним чуть больше нюансов - современные IDE предоставляют хорошую интроспекцию объектов в дебаге, поэтому найти то, что toString продолбан чаще всего получается уже в логах с прода, где он не дает никакой информации.

А вот с equals и hashCode все веселее и проще - они иногда приводят к дням веселой отладки в попытках понять что же происходит.

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

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

Почему не статический анализ кода? 

Инструмент для обнаружения проблемы можно построить и не с нуля, используя средства статического анализа кода типа findbugz, checkstyle, pmd.
Все они предоставляют возможность расширения набора правил анализа, и все они open-source.
И все они обладают избыточным набором правил анализа на все случаи жизни, который можно и приходится настраивать.
И ни один из указанных инструментов не может проверить нужные мне условия прямо из коробки.
И самое главное - редко когда и мало кто ставит этот статический анализ кода в таком месте своего жизненного цикла разработки так чтобы он прерывал сборку проекта.
Мне же хотелось иметь средство, которое по умолчанию будет останавливать сборку проекта.

Почему именно так ? 

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

Идея решения проста - в процессе написания кода нужно поставить одну аннотацию, остальное компилятор при помощи процессоров аннотаций сделает сам.
Естественно процессор аннотации нужно написать, естественно аннотацию нужно повесить на класс, и если этого не сделать, то никакой процессинг не сработает.
Но аннотацию нужно поставить одну, а методов про которые нужно не забыть  - три, так что уже выигрываем.
Аннотаций я пока реализовал две:
@Pojo - проверяет что у класса определены  equals, hashCode, toString
@Helper - проверяет что класс соотвествует идее хэлпера (все методы статические, конструктор приватный, все поля константы, никакого состояния иметь не должен).

В натуре

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

При попытке компиляции тестового проекта вы увидите вот такую вот своершенно неизящный вывод в консоли.

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

Мысли по ходу.

Мыслей в связи с этим вот pet project у меня накопилось больше, чем сам проект.

1. Казалось бы фундаментальнейшая и низкоуровнвая вещь, такая как процессор аннотаций, должна быть вылизана, задокументирована и спроектирована очень хорошо. Но вот с документацией вообще швах.
2. Информации и примеров того как это делать правильно в интернете не очень много. Свою подборку ссылок приведу в конце.
3. Я не нашел ни одного вменяемого метода для тестирования этих процессоров аннотаций, кроме как создать отдельный проект в котором эти самые аннотации будут развешаны на классах дающих нужные кейсы.(смотри апдейт ниже) В мыслях крутиться использования инфраструктуры для тестирования плагинов к maven, но этот ад мы прибережем для следующей серии нашей мыльной оперы.
4. Если отбросить лично мои заморочки и скомбинировать подход с построением AST, то анализатор может получится весьма и весьма мощный.
5. Сразу нужно думать про нормальный репортинг, посколько API процессора аннотаций ничего кроме как минималистичного вывода в консоль делать не дает. То есть проанализировать код, найти плохое место в нем вы конечно можете но вот отрапортовать об этом будет сложно. Нужно писать что-то сбоку.
6. Чтобы вся эта радость нормально работала библиотеку с аннотациями и процессорами нужно подключать к мавену в scope = provided. Так и только так!!! Иначе зависимость на аннотации и анализатор полезет дальше транзитивно, а мы помним что это всего лишь инструмент, не более того.

Ссылки

1. Пост на хабре вдохновивший меня сделать это.
2. Туториал по похожему кейсу.
3. Фундаментальная статей про процессинг аннотаций в Java. Все разжевано и разложено по полочкам.
4. Еще один хороший туториал в трех частяхпостах (раз, два, три)

UPD 22.11.2016 В процессе археологических раскопок кургана Гитхаб наша экспедиция нашла древний артефакт для тестирования кода процессоров. Подключили, попробовали - работает!

Напочитать: Околосервисный выпуск

1. Gradle отрелизил версию 2.5. Две основные плюшки в релизе - непрерывная сборка при изменении исходников и правила замены исходников чтобы не компилить все и каждый раз.Ну и отличная презенташка на тему того что Gradle умеет.
2. Хорошая статья про монады. Оказывается я давно ими пользуюсь.
3. Amazon выпускает свою имплементацию TLS  - s2n.
4. Отличный маленький и жутко полезный инструмент от Алексея Рагозина - jvm-tools.
5. Интересная оберточка для транслирования исключений - ET (github).
6. Может быть в Java 9 выпилят Unsafe. Непонятно зачем, но понятно что из этого будет.Тут вот контрнаброс про это.
7. Отличное выступление Чеда Фаулера про то как они Wunderlist на микросервисы распиливали.


8. Случилось что-то страшное или Скайп начал поворачиваться лицом к людям. Вот даже релизят АПИ.
9. Maven Best Practices.
10. Отличное  live-demo того что можно сделать с помощью Spring Boot (это если кто не знает платформочка для создания микросервисов)

11. Транзакции в распределенной (как правильно - распределенная или распердЮленная? :)) системе - ну может быть. Паттерн Saga под капотом (еще тут от MS про него же). 

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

Лето. Затишье. Да и мне уже в отпуск хочется.

1. Долго и нудно о том что такое исследовательское тестирование. От авторов самой концепции исследовательского тестирования. 
2. О полуавтоматизации для тестирования локализаций в Netflix - тут. 
3. Netflix Test Studio уже как-то попадала ко мне в напочитать, но вот тут про нее более развернуты рассказ. Точнее про то почему в нее пришлось воткнуть Kafka.
4. Еще один рассказ как преуспеть с интеграционными тестами - на этот раз из мира .NET - но да суть неизменна.
5. Недотестировали. забили, забыли на 500 миллионов долларов - баги в космосе дорогие.
6. Большая книжка про то как начать автоматизировать на Python - тут.
7. Онлайн-конференция TestLabs пройдет 25 июля. Инфа тут.
8. Мне вот порой кажется что тестировщики без пирамид не могут. Нуващеникак!!! Вот еще раз про пирамиды и качество. 
9. Коротенько и емко про то что стоит за тестированием на основе моделей - состояния и их диаграммы.
10. Рассказ про кошерный BDD от John Ferguson Smart - того самого который сделал Thucydides (ныне Serenity)
11. Рассказ от Etsy о том как они на LXC+Chef строили свою тестовую инфраструктуру - раз и два.
12. Infer. Статический анализатор кода от Facebook. Ссылочки (раз, два, три).
    Из последнего  white-paper-а вы можете узнать что:
    - большие продуктовые компании инвестируют в инструменты статического анализа.
    - Infer был изначально сделан не в Facebook, Facebook попробовал его и решил купить компанию, стоящую за Infer (Monoidics).
    - этот инструмент анализирует код композитно - то есть не весь каждый раз, а только изменения и натягивает эти изменения на предыдущие результаты и за этим стоит математика.
    - есть отдельная система которая по хэшам определяет места в коде чтобы понимать какой changeset что дает на продашене.
    
    К чему это все здесь?  К тому, что не нужно стесняться делать свои инструменты для обеспечения качества своего кода. Статические анализаторы кода могут поймать только общие вещи, расширять их можно (и даже нужно), но иногда приходится писать и свои. Если у вас получится, то вас купит Facebook :). 

Книга: Сэм Кейнер. Руководство фасилитатора. Как привести группу к принятию совместного решения

Дочитал.

Это не просто книга, а почти что фундаментальная книга.

Пару лет назад мне довелось присутствовать на двух мероприятиях, которые для нас проводили тренеры (фасилитаторы) из одной Очень Известной Компании.
Оба мероприятия были двухдневными, оба фасилитатора были профессионалами своего дела.
Но оба не довели группу до момента инсайта.
Точнее даже так - им обоим было не суждено это сделать, но они старались.

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

О самой книге.

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

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

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

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

Это настольная книжка на долгое время потому что фасилитация практический навык, который нужно просто тренировать.

Оценка 9/10.


Отдельное спасибо хочу сказать Диме Лазареву, который согласился привезти мне экземпляр этой книги на CodeFest в Новосибирск в этом году.

Напочитать : Накипевший выпуск.

1. Если слова  Java +  JNI + С++ вам знакомы и вызывают боль то вам может быть полезно тут.
2. Отличный перевод манифеста Twelve-Factor-App  на Хабре.
3. Stefan Tilkov на Craft Conference 2014 рассказывал об архитектуре, архитекторах и пичальках. Смотреть тут.
4. О том что Hola ссучилась и какие угрозы могут нести расширения в браузерах  - как для пользователей, так и для продуктов , с примерами и картинками.
5. Очень пространное эссе о трудностях общения компилятора Java и JVM.
6. Step-by-step guide про то как начать с node.js, если вам конечно не противно.
7. Новый статический анализатор кода от Facebook. Правда вроде как без правил по которым анализировать, зато опенсорс, OCaml под капотом и все понты, дада.
8. Простые правила написания безопасного кода. Ну совсем простые.
9. Как дебажить maven сборку - написано тут, несмотрите на слова Eclipse.
10. Рассказ от Spotify о том как они мигрировали базу данных  пользователей без downtime c PostgreSQL на Cassandra.
11. Как пользоваться FUSE через С и Java и вроде бе даже без крови. 
12. Вопросы которые нужно задать себе когда хочешь странного SOA микросервисов.
13. Release plan на Java 9 готов, осталось взять и написать. Плохая новость - не будет JSON API, Money & Currency API. Хорошие новости - тут уж на суд каждого. 
14. О том как хорошо потрахаться с try-with-resources через мутационное тестирование с pitest.
15. О том как устроен UI десктопного плеера Spotify, причем здесь богомерзкий javascript и Chromium Embedded Framework. И такого будет дальше только больше. (Лавеча слышал цифру что Facebook переиспользует более 50% кода какого-то компонента в iOS и Android приложениях через этот ващ  Javascript).

Следующий про тестирование.

Mad Minsk - SQA Days 2015

Первый раз я был на SQA Days в Киеве в 2012 году.
Но так то Киев, 2012 год, апрель, и вообще первый раз на SQA Days, первый же раз на конференции вне Москвы.

До сих пор не забуду тот совершенно нетомный вечер, который мы отгуляли с Лешей Лупаном, Шницель-Хаус на Саксаганьского, прогулку по центру Киева, шарж на наши довольные бородатые морды лиц и неумолимо теплый (+20 градусов после захода Солнца), ромовый антураж Киева, который стучит в висках до сих пор. Аххх!

Место : Президент-Отель, Минск, Республика Беларусь.
Площадка средненькая (Президент-Отель).
Основное нарекание вызывает только площадка для трека C - 11 этаж, отвратительная вентиляция, при условии попадания в трек 100+ человек вызывает желание слушать доклад прямо из лифта.
В треках А и B такого не было.

Организация
Для конференции в 900 человек (планово, не знаю сколько было по факту) организация на троечку. От коллег слышал нарекания по обеду - во вторую или третью смену обеда не всем доставалось еды, при том в оба дня. Кофе + печеньки + место для общения было всегда, на официальное афтепати мы не поехали, предпочтя ему "Раковского Бровара".
В первый же день стало ясно что распределение докладов по аудиториям (500 большой зал, 200 малый зал, 200 еще один малый зал на 11 этаже) никак не соотносится с интересностью докладов. То есть несколько интересных докладов были в зале С с плохой вентиляцией и народу туда приваливало больше плановой емкости, в то время как основной зал на 500 человек был почти пустым. Я, конечно, могу ошибаться, но банальная голосовалка за 2-3 недели до конференции решила бы проблему распределения людей по залам.
Ну и сбор фидбека - бумажный листочек в сумочке, который надо заполнить и отдать. Который даже я естественно не заполнил и не отдал.



Доклады - день 1.
Rex Black, Test Estimation - слайдоменты, ад, трэшугар про вотерфолы.
Игорь Хрол про автоматизацию тестирования - весело, задорно, половина про Grail, уже видел.
Андрей Мясников про Gherkin и Ruby - сам доклад наверное хорошо, но Ruby и Gherkin заставили меня ретироваться.
Павел Асанов про автоматизацию тестирования API в 2GIS - очень хорошо.
Андрей Стахевич про appium в облаках - сравнительный обзор облаков работающих с аппиумом, на этом все.
Катерина Овеченко - отличнейший доклад про фаззинг.
Евгений Кривошеев про Points Of View - выступал Женя очень живо, но я не уверен что аудитория восприняла хотя бы даже часть.
Роман Иовлев про Micro Model Based Testing - мне не очень, из нового - названия каких-то инструментов для SBT.

Доклады  - день 2.
Алексей Лянгузов, беседа про тестовые данные. Действительно беседа.
Дмитрий Гуменюк Report Portal - интересная презентация продукта, очень похож на наш Watson, но более ориентирован на то, чтобы туда еще и внешний заказчик смотрел.
Илья Фомин про Chef, Puppet,  и прочее и как с этим жить - доклад хороший.
Никита Макаров, Микросервисы для автоматизации тестирования - пришлось сходить :).

Мой доклад.
Был сильно упрощенным, без технических деталей, как например, на прошлогоднем CodeFest. Причин на то две - хотелось поделится именно идеей и рассказывать техническое мясо в течении 35 минут слота трудновато.
Много вопросов про ботов, про ограничения, несколько подрывов шаблонов на тему " - Вы что бл@#$ продакшен тестируете ??? - Да, тестируем :)".

Впечатления
Отрасль тестирования у нас никуда (в этом году уж точно) не движется. Вообще. Практиков, которые исследуют что-то новое, пытаются встроить это в себя и поделится потом с окружающими опытом - мало, катастрофически. И соотношение сторон даже не 10 на 90, а 2 на 98. Грусть, печаль, беда.

Про Минск и Беларусь
Первый раз  был в Беларуси.
Как только проехал скульптуру зубра на выезде из аэропорта сразу пропадает ощущение того что ты в Беларуси - дороги как в Германии, ни швов ни ям в асфальте, обочина чистая, одуванчики растут по линеечке, лес ухоженный. И так до первого дорожного указателя :).
В целом все очень культурно - продавать пиво можно до 23, а вот пьяных и бутылок на улицах нет. Сфера обслуживания конечно не ахти -  официанты/официантки не сильно мотивированы.

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

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

Напочитать: Test... Test me harder!!!

 Уже на этой неделе в Минске состоится SQADays. Ну а пока не наступила - выпуск с сильными уклоном в тестирование.

1. Автоматизированное тестирование JavaFX приложений - с примерами и картинками.
2. Очень многие сейчас увлекаются всякими Chef-ами, Puppet-ами и прочими Ansible-ами. А ведь это все надо тоже тестировать  - инфраструктура как код - это небесплатно.
3. Замечательный набор подсказок для тестировщиков что можно делать с консолью Google Chrome.
4. О непростых взаимоотношениях разных версий Opera и как с ними жить из-под webdriver - Алексей Баранцев.
5. О том как построить схему связей модулей в проекте на PowerShell и Graphviz - тут. Причем здесь тестирование и обеспечение качества - а вот сами должны догадаться!
6. Замечательный, хоть и длинный пост про TDD и что "невсетакпросто" и флейм в комментах.
7. Ребята из LMAX Exchange (это контора, которая дала миру Disruptor, если чо) плюют в морду ребятам из Gooogle, которые говорят что end-to-end тесты - это дорогостоящая фигня.
Плюют обоснованно. От себя могу добавить - обращение с большим массивом end-to-end тестов требует принципиально других инструментов и подходов. Существующие инструменты (Continuous Integration решения, большей частью) не обладают теми свойствами которые нужны для постоянно работы с большим количеством end-to-end тестов (отчеты, логи, анализ запусков на разных окружениях, продолжать можно долго). И либо вы дальше строете/пристраиваете/достраиваете что-то свое (как мы - микросервисы), либо начинаете кричать о том, что end-to-end тесты = ( долго + дорого + хрупко + неэффективно * и вообще говно).  Меняйте mindset.


На SQA Days в Минске я как раз буду рассказывать о том как мы строим и используем микросервисы для наших (в том числе end-to-end) автоматических тестов.

Напослушать: CodeFest, RadioQA и продолжение банкета

Началось все еще на CodeFest, когда Таня Писчасова предложила поговорить про Мир без тестировщиков. Что из этого получилось - на видео ниже, там и моя говорящая (с трудом %)) тушка тоже присутствует. Однако, результаты квартирника не устроили ни меня (форматом большей частью), ни Татьяну, поэтому Таня предложила повторить - Леша Виноградов как раз организовал подкаст про тестирование, в первый выпуск которого мы и вписались. Ну и в качестве десерта - Роман Сергеевич Ивлиев, там же, на кодефесте вещал про то как они боролись со скачками активности - здесь все - Черные лебеди, теория ограничений, Битрикс.

Напочитать: Пятнашки

1. Сразу две статьи про легковесные реализации многопоточности в Java - раз и два.
2. С релизом 1.6 Docker ступает на тропу Windows. Ну и еще куча всякого в релизе. 
3. Еще не до всех дошло что можно ускорять Android эмулятор за счет тупого изменения архитектуры процессора в настройках. Будем повторять, чо.
4. Мутация JSON от Google  - jsonnet. Интересно, выживет ли.
5. Интересная возможность отлаживать вэбчик в разных мобильных браузерах.
6. Набор прикольных утилитарных библиотечек от Zero Turnaround - zt-zip, zt-exec, zt-process-killer. Молодцы,чо.
7. Пара интересных статей про Traceability на Large-Scale - про то как Facebook делает это через  логи и про то как Google делает это через интроспекцию.
8. Еще раз про Ansible. Имхо на масштабах до 100 машин - хорошая штука.
9. Вышел Guice 4.0 с улучшенным саппортом Java 8.
10. Интересный инструмент для анализа бинарной совместимости релизов - jQAssistant.
11. Windows будет теперь релизится по-другому - это если суть. Детали тут.
12. Отличный обзор Continuous Delivery от Google/Amazon/Facebook если кто-то еще не читал/смотрел. Исполняет Noah Sussman.
13. "Вы не любите JavaScript? Вы просто не умеете его готовить! " и тому подобное.
14. Вышел новый technology radar от Thoughtworks.
15. Интересная фигня от Airbnb - Airpal.

Книга: Норм Керт "Ретроспектива проекта"

Вторая книга от издательства Дмитрия Лазарева, в издании которой я участвую.
Очень трудно писать на тему ретроспективы проектов, особенно после того как начал писать цикл постов про то как делать ретроспективу в команде. Но попробую.

Итак, структура книги мне в целом понравилась.
Единственное что кажется нужно править - это главу про упражнения ретроспективы - очень уж  она объемная, и в голову не влезает никак.
В остальном - структура книги отлично расскажет вам "карту территории" - как подготовится, как продать, как начать, мелкие, но полезные тонкости проведения ретроспективы.


Про содержание (субъективно).

Эта книга не про Agile, от слова совсем. Трудно себе представить здоровый гибкий процесс, в котором люди испытывали бы такой градус недоверия или необщение друг с другом и ничего  с этим бы не делали. Эта книга не про маленькие (до 5-7 человек) команды, хотя сам автор пишет что больше 30-35 человек он не фасилитирует в рамках ретроспективы, обычно до 15.

Эта книга, наверное, о самом важном чем может обладать "стая товарищей" называемая "командой разработки" - доверие и способность учиться на своих ошибках через их признание и анализ.
Скажу честно, что мне ни разу не приходилось работать  в таком коллективе, где были бы напрочь отбиты оба этих аспекта. (Хотя вру - приходилось,  но мы там ретроспектив не делали.) Работа над установлением доверия - действительно догий и тяжелый труд.  А для того чтобы "сломать психику" человека в сторону признания своих ошибок и адекватного анализа их - вообще требуется очень много времени. Но опыт автора книги по части проведения ретроспектив в различных коллективах сильно больше моего, поэтому нет оснований не верить ему.
Книга делает очень много акцентов на прошлом проекта для понимания и выявления причин тех или иных действий/явления на проекте, чтобы показать одним участникам ретроспективы, что с другой стороны баррикад сидят "тоже люди".
Пожалуй эта книга является самой крутой методичкой по части icebreaker-ов.
И пожалуй эта книга лучше всего продает роль фасилитатора ретроспективы - при том продает объективно.

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


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


Оценка 7/10