Еще раз про Automation Bias: TDD, BDD и роющие осы

Вместо предисловия

Это Сфекс:

Сфекс это весьма распространенный род роющих ос.
Они выкармливают личинок парализованными насекомыми. Но помимо этого у них есть одна весьма примечательная особенность, которую выяснили проводя на них бесчеловечные эксперименты.

Например, прежде чем затащить парализованного кузнечика в свою нору Сфекс обязательно оставляет его у входа и проверяет свой дом. Пока Сфекс исследует логово - экспериментатор отодвигает кузнечика на несколько сантиметров. Выбравшись наружу сфекс подтаскивает кузнечика к логову и заново принимается исследовать свое логово. И это может продолжаться до бесконечности, пока Сфекс не умрет от истощения. Философы любят приводить этот эксперимент как пример того, как внешне весьма разумное поведение (ведь проверить логово вполне разумно) может в действительности быть совершенно бездумным.
Еще Сфексы для своего размножения используют тела мертвых насекомых, которыми нашпиговывают нору и откладывают туда яйца. Собрав четыре кузнечика, отложив яйца и замуровав, Сфекс приступает к следующей. Но в ходе все тех же жестоких пыток насекомых выяснилось, что Сфекс не считает количество кузнечиков в норе. То есть, если кузнечик в норе, то он уже посчитан. Если этого кузнечика упрут муравьи или экспериментатор, то Сфекс этого не заметит.
Еле другой пример - Сфекс таскает кузнечиков за антенну. Если кузнечику обломать антенны, то Сфекс его не сможет утащить. Он даже не будет пытаться тащить кузнечика за внешне похожую лапку.

Таких издевательств над Сфексами было произведено много. Все они показывают, в частности, то, что у Сфексов очень сложное для насекомого, но при этом до крайности алгоритмизированное поведение. Сфексы отвратительно адаптируются к неожиданным обстоятельствам и внезапным изменениям окружающей среды, но их сложное алгоритмизированное поведение помогло им стать весьма распространенным видом насекомых.

Автоматические тесты (даже за пределами TDD и BDD) это маленькие, трудолюбивые Сфексы - бесконечно тупые, хреново помогающие в обнаружении неожиданных сюрпризов и предотвращении не очень ожидаемых катастроф. Но при всем при этом у них, как и у Сфексов, есть ряд полезностей, неправильная оценка которых может быть весьма опасной.

Увы, люди тоже порой уподобляются Сфексам.



А теперь про TDD и BDD

BDD - прекрасный, местами даже изумительный инструмент. Писать тесты человеческим языком это безумно круто, пока вы не наткнетесь на ограничения в выразительных средствах. Человеческий язык все же сильно богаче, чем имеющиеся фикстуры, сколь бы много вы их не написали. В итоге совершенно конские усилия начинают тратиться на написание фикстур для прикладывания усложненного, псевдонатурального языка тестов к настоящему API этих самых тестов. Брайан Марик нашел замечательнейший пример сложной конструкции в BDD:

Feature: Purchase Items in Cart

  Scenario: Using Existing Billing and Shipping Information
    
    Given I have an existing account
    And I have previously specified default payment options
    And I have previously specified default shipping options
    And I have an item in my shopping cart

    When I sign in to my account
    And I choose to check out

    Then I see my order summary
    And I see that my default payment options will be used
    And I see that my default shipping options will be used

Example taken from http://johnwilger.com/blog/2012/01/21/acceptance-and-integration-testing-with-kookaburra/

 Сложный, не очень читабельный тест, который в той же статье предлагают писать вот так:

describe "Purchase Items in Cart" do
  example "Using Existing Billing and Shipping Information" do
    given.existing_account(:my_account)
    given.default_payment_options_specified_for(:my_account)
    given.default_shipping_options_specified_for(:my_account)
    given.an_item_in_my_shopping_cart(:my_account)

    ui.sign_in(:my_account)
    ui.choose_to_check_out

    ui.order_summary.should be_visible
    ui.order_summary.payment_options.should be_account_default_options
    ui.order_summary.shipping_options.should be_account_default_options
  end
end

# Example taken from http://johnwilger.com/blog/2012/01/21/acceptance-and-integration-testing-with-kookaburra/

Уже больше похоже на unit тесты, больше укладывается в нормальный процесс работы того же программиста. Можно еще меньше маяться дурью и написать тест простым кодом. Да, его будет сложнее показывать заказчику/бизнесу, но и в сложных примерах приведенных выше он все равно нихрена не поймет, а лишних усилий они будут кушать много.

Это отлично, когда бизнес, тестировщики и разработчики работают вместе над тестами и продуктом. BDD это весьма заманчивое приглашение к такому сотрудничеству. Но когда оно начинает перерастать в подобные ветряные мельницы, которые никому не нужны - с этим надо завязывать.

При этом BDD и TDD это не для того чтобы убедиться что что-то хорошо работает. Если вы все еще так думаете, то отмотайте вверх и прочитайте часть про Сфексов еще раз. "Примеры" из BDD это не тесты и не спецификация. Они неполны и далеко не всегда корректны для того, чтобы их так называть. Они, как и тесты в TDD, нужны для того, чтобы находить куски приложения, которые вам непонятны, которые сложно понять/сделать, в конце-концов куски, для которых банально нет достаточно информации для их реализации.

При этом существующая для TDD/BDD догма о 100% зеленых тестов демотивирует на написание и регулярный прогон негативных тестов, или тестов, результаты которых нам заранее неизвестны. Эти тесты могут быть очень эффективными и полезными, но у них мало шансов регулярно быть зелеными. То, что эти тесты не нужны в рамках TDD/BDD понятно - эти трехбуквенные комбинации нужны для того, чтобы воздействовать на разработчика как лампочка в эксперименте Павлова, а не для попыток выработать уверенность в разрабатываемом приложении, потому как эта уверенность подобна уверенности Сфекса, который по факту затаскивания в норку четырех кузнечиков спокойно обрек своих будущих детей на голодную смерть.