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

Сборная солянка видеодокладов для самообразования на разную тематику - Выпуск 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. Будете ли вы использовать TDD? ДАПочему? П…