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

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

интересно, это Андрей? (тут)

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

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

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

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

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

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

Вернемся к докладу.

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