пятница, 14 января 2011 г.

Моки - это не стабы

Недавно прочитал статью Фаулера "Mocks Aren't Stubs", которая напрямую касается темы следующей пати - моков, стабов и их применения.

Ниже поделюсь мыслями о прочтённом.
В этой статье мне показался особенно интересным рассказ о двух подходов к тестированию - Classical и Mockist. Оба подхода рассматриваются  в различных ситуациях, показывающих различие в мышлении людей, придерживающихся разных подходов.

Рассказ об этих подходах поставил для меня точку в том споре, который мы вели с Алексеем Рогаткиным во время первой пати - о том, как лучше использовать моки и для чего их надо использовать. Я понял, что я сейчас больше склоняюсь к mockist, а Лёша сейчас более склонен к classical. И наш спор был не более чем обсуждение двух разных подходов, и оба эти подхода имеют право на жизнь.

Но мне стало интересно, у какого из подходов больше приверженцев. Поэтому я хочу спросить у читателей: если вы пишите тесты к своему коду, то к какому варианту склоняетесь вы - mockist или classical?

Я же для себя поставил задачу опробовать на себе оба подхода, чтобы сравнить. Так что попробую в ближайшее время писать тесты в стиле classical TDDer.

Кстати, как думаете, какой корректный перевод будет для приверженцев этих направлений? Фаулер использует сочетания classical TDDer и mockist TDDer. По всей видимости имея ввиду classical test driven developer и mockist test driven developer. По-русски вариант звучит как разработчик через классический тесты и разработчик через мок-тесты. Но как это сказать короче, чтобы не нужно было произносить столько слов? Есть идеи?

9 комментариев:

  1. классический тддшник, мок-тддшник :)

    ОтветитьУдалить
  2. даа, мне пока такой вариант больше всего нравиться :)
    правда можно мок-тддшника вообще называть мокер - коротко и ясно.

    ОтветитьУдалить
  3. По своему опыту могу сказать, что пихать моки везде и вся очень плохо. Конфигурация тестов становится очень большой, а behavior проверка весьма хрупка(тест знает о внутренней структуре класса, и сломается он впервую очередь при изменении оного). Поэтому имхо надо использовать моки для тяжелых объектов(remote сервисы, базы данных, файловая система). Итого, я убежденный классический тдд-шник.

    ОтветитьУдалить
  4. да, моки повсюду - это явный перебор. Хотя наверняка есть и те, кто наверняка так делает.
    но как и во многих других вопросах, я придерживаюсь мнения о том, надо придерживаться золотой середины. Порой надо тестировать и поведение, а порой надо наоборот проверить только состояние. Иногда надо протестировать модуль совершенно независимо от других модулей, а иногда это просто невозможно. Короче говоря, я хочу постепенно придти к тому, что в каждой ситуации буду выбирать наиболее оптимальный вариант.

    Я думаю, все все согласятся с тем, что быть сугубо classical или mockist tdder - это ограничивать себя в принятии решений. Конечно, так проще - решение всегда заранее известно - либо проверяем состояние, либо поведение и всё просто.

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

    в общем, чтобы быть крутыми джедаями, надо познать обе стороны силы :-D

    ОтветитьУдалить
  5. Вообще нужно исходить из того, какие тесты ты пишешь. Есть модульное тестирование, это, например, если тебе нужно оттестировать свой модуль, пока чужие модули отсутствуют или работают не правильно.
    Есть интеграционное тестирование, когда тебе нужно понять, что твой модуль с зелёными модульными тестами правильно работает с чужим модулем, у которого также зелёные модульные тесты.
    Как понятно из выше сказанного, интеграционное тестирование проводится после модульного.
    В условиях contious integration, вероятно, можно обойтись без моков, но у меня пока не было опыта работы в команде работающей по True TDD, когда закоммиченный код весь покрыт тестами и они все зеленые.

    ОтветитьУдалить
  6. А, варианты названий. Если брать опыт американских коллег, они любят заменять сложные аббревиатуры созвучными словами осмысленными словами. Например Hot potatos - HTTPS.
    Мне вот в голову только такое пришло: "мок-тыдынец" и "класcический тыдынец" :)

    ОтветитьУдалить
  7. да, последний вариант названий мне нравиться больше всего :)
    клёво звучит: "ну что, тыдынцы, за работу"?

    насчёт True TDD - любопытно было бы какой-нибудь проект небольшой взять и написать полностью в стиле TDD. Хочется понять, больше плюсов от этого или проблем.... скоро начинаем проект длительностью где-то на месяц, надо будет попробовать это. А то проекты совсем без тестов писали и не раз. Проекты где тесты есть, но не полные тоже были. И ни разу не пробовал полностью покрыть покрыть проект тестами... ну или хотя бы процентов на 90 :) я считаю, что это очень избыточно, но не попробуешь - не будешь уверен.

    ОтветитьУдалить
  8. Насчет code coverage хочется кое-что разъяснить. Мне понравилось выступление одного разработчика http://vimeo.com/5403743. Там была фраза: "Вот тут некоторые менеджеры хвалятся, что у них 100% code coverage... И что? Если это многотредовое приложение, то засуньте себе этот coverage в одно место." Это я к тому, что полное покрытие не гарантирует правильность работы программы и к тому, что в gui программах очень сложно достичь отметки 90 :-). Coverage полезен не цифрой(кто больше мамонтов убил), а тем, что позволяет обнаружить места, не покрытые тестами.

    ОтветитьУдалить
    Ответы
    1. странно, при чем тут ТДД) ТДД изначально предпологает, что 100% написанного функционала покрыто тестами... Ни строчки кода без теста, ведь так?

      Удалить