К основному контенту

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

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

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

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

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

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

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

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

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

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

Комментарии

  1. Я так и не понял, ты за или против?

    ОтветитьУдалить
  2. За что или против чего? :)
    Я за тесты руками разработчиков. Но тип теста определяется исходя из простоты, целесообразности, скорости, удобства и тд.

    ОтветитьУдалить

Отправка комментария

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объек

План "Б" или как прикольно провести субботний день

Всем привет. Вчера состоялась конференция " План Б ". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек. Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля. Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера) Здесь приведу лишь те вещи, которые мне запали в мозг Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а" Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно ча

Переключите тумблер или умные люди дурного не посоветуют

Навеяно интересными вопросами про TDD после  вчерашнего выступления . Uncle Bob : " Flipping the Bit " Подробнее постараюсь перевести чуть позже, пока только это: Как определить, что у коллеги (или у вас) ТУМБЛЕР переключен?  Если ваши ответы на вопросы ниже совпадают с приведенными - то все хорошо :) Мантра: Сможете ли вы выполнить работу быстрее используя TDD? ДА Существуют ли какие-либо задачи, которые вы можете выполнить быстрее без TDD? НЕТ Я понимаю, что TDD может помочь в долгом проекте, а что если у вас короткая задача? Будете использовать TDD? Да, потому что TDD быстрее даже в короткой перспективе Что если времени реально не хватает, и босс стоит над душой, будете ли вы использовать TDD? ДА В любом случае? ДА Есть ли случаи, когда вам не нужно использовать TDD? НЕТ Представьте себе что вы на звездном корабле Enterprise ( Star track ) и осталась всего секунда до взрыва антиматерии. Все что вам нужно, чтобы избежать этого, поменять один IF. Будете ли вы и