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

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

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

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

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

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

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

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

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

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

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

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

Резюмируя (тут то, что срезонировало с моим понимаем проблемы и я под этим подписываюсь):

• Тесты заставляют разработчика думать
• Разработчики должны иметь возможность запускать тесты на своем компе
• Тесты решают проблему 95% багов, остальные 5%  мы чиним быстро, если в них втыкаются.
• Для хороших тестов надо уметь переключать mindset с "разработчик" на "тестировщик". Это разные типы мышления.