Несколько вопросов о процессе BDD от новичка

Недавно я прочитал несколько статей о BDD, чтобы понять, о чем идет речь. Теперь я получаю базовое понимание, но все еще не понимаю весь процесс.

Вот что я думаю сделать в процессе BDD:

  1. Все заинтересованные стороны (BA, клиент, Dev, QA) собираются вместе, чтобы обсудить требования и написать согласованные функции на карточках историй. Здесь я беру в качестве примера функцию «регистрации пользователя»:

    As a user,
    I want to register on the system,
    so that I can use its services
    
  2. Создайте несколько сценариев в формате Given/When/Then, и вот один из них:

    Scenario: user successfully register
        Given an register page
        And an un-registered user
        When the user fills username "Jeff" and password "123456"
        And click on "Register"
        Then the user can see a "Success" message
        And the user "Jeff" is created in the system
    
  3. Реализуйте этот сценарий с помощью какой-нибудь среды тестирования BDD, скажем, cucumber-jvm, например:

    import cucumber.api.java.en.Given;
    
    public class Stepdefs {
        @Given("an register page")
        public void an_register_page throws Throwable {
            // ...
        }
        @Given("an un-registered user")
        public void an_register_page throws Throwable {
            // ...
        }
        // ...
    }
    

    для шагов один за другим.

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

Что мне теперь делать?

Что мне теперь делать? Нужно ли мне обсуждать этот сценарий со всеми заинтересованными сторонами? Что касается BA/Customer/QA, я не думаю, что они действительно заботятся о реализации, не стоит ли обсудить это с другими разработчиками?

Предположим, после того, как я обсужу это с некоторыми другими разработчиками, мы договоримся разделить его на несколько небольших частей. Можем ли мы сделать эти небольшие части как «сценарии» с форматом Scenario/Given/When/Then, как мы только что сделали с огурцом-jvm, или мы можем использовать JUnit, как мы обычно делаем в TDD?

1. If choose "cucumber-jvm", it seems a little heavy for small part
2. If choose JUnit, we need to involve more than one testing framework in a project
3. Is it the best if there is a single testing framework to do both things (not sure if there is)

Предположим, я выбираю вариант 2, используя JUnit для небольших задач.

Вот что я буду делать после этого решения:

  1. Теперь мы создаем новые небольшие тесты для управления реализациями, такими как создание пользователя в базе данных, как мы обычно делаем в TDD. (красный->зеленый->рефакторинг). И нас пока не волнует тест на огурец Scenario: user successfully register (который провален), просто оставьте его там. Правильно?

  2. Мы разрабатываем больше небольших тестов с помощью JUnit, сделали их красными -> зелеными -> отрефакторили. (И неполный тест на огурец всегда проваливается)

  3. Пока не пройдены все маленькие тесты, переходим к тесту на огурец Scenario: user successfully register. Завершите его и убедитесь, что он наконец стал зеленым.

  4. Теперь разработаем другой сценарий, если несложно, то можем реализовать просто с огурцом, иначе придется его разбивать и писать несколько jUnit-тестов

Определенно есть много недоразумений, даже самых элементарных. Потому что я не вижу особой пользы от BDD, за исключением части «обсудить со всеми заинтересованными сторонами».

Где моя ошибка? Признателен за любые предложения!


person Freewind    schedule 29.11.2015    source источник


Ответы (2)


  1. Не начинайте с входа в систему; начните с того, что отличается от других систем. Почему кто-то входит в систему? Почему они хотят пользоваться сервисом? Жестко закодируйте пользователя, притворитесь, что он вошел в систему, сосредоточьтесь на значении.

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

    Given Jeff isn't registered with the site
    When he registers with the username "Jeff" and password "123456"  
    Then his account creation should be confirmed  
    And he should be invited to log in for the first time.
    

    Посмотрите «декларативный и императивный» здесь, чтобы узнать больше об этом.

  3. Если ваш пользовательский интерфейс действительно меняется, попробуйте сценарий вручную, пока пользовательский интерфейс немного не успокоится. Тогда будет проще автоматизировать. По мере того, как вы переходите к более стабильным сценариям, лучше сначала автоматизировать (в стиле TDD).

  4. Что теперь делать? Что ж, большинство людей не пишут тесты на уровне класса для пользовательского интерфейса, поэтому не беспокойтесь об этом, пока не начнете вытеснять уровни контроллера и презентатора. Обычно проще иметь фреймворки на одном языке, но два разных фреймворка — это нормально. Cucumber/RSpec, JBehave/JUnit, SpecFlow/NUnit — довольно типичные комбинации. Делайте наименьшее количество, необходимое для того, чтобы первый сценарий заработал. Это не будет много, потому что вы можете жестко запрограммировать многое из этого. Второй сценарий начнет представлять более интересное поведение, и тогда вы начнете видеть, как появляются ваши тесты на уровне класса.

Кстати, BDD начался на уровне класса, так что вы можете делать то же самое с классами; придумайте пример того, как вы могли бы его использовать, напишите в комментариях «Дано, когда, тогда», если ваш фреймворк уже не работает таким образом, а затем заполните пробелы!

  1. Да, ваш сценарий Cucumber будет красным, пока он не станет другим.

  2. В идеале вы должны выполнить один последний модульный тест и сценарий Cucumber одновременно, а не просто написать немного дополнительного кода. Очень приятно видеть, что он, наконец, стал зеленым.

  3. Первоначальная цель BDD заключалась в том, чтобы избавиться от слова «тест», поскольку оно заставляет людей думать о таких вещах, как TDD, как о тестировании. TDD действительно о чистом дизайне; понимание обязанностей и поведения вашего кода точно так же, как сценарии помогают вам понять возможности и поведение вашей системы. Должно быть нормальным писать как сценарии уровня системы , так и тесты уровня класса.

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

Похоже, что вы находитесь на правильном пути, что касается остального процесса. Вы также можете найти некоторые другие ответы BDD в моем профиле полезными для вас. Поздравляем и желаем удачи!

person Lunivore    schedule 01.12.2015

Я думаю, что сначала нужно выполнить регистрацию/вход в систему, когда вы изучаете механику выполнения BDD. Почти все понимают, почему вы хотите войти в систему, и все понимают, что система должна знать, кто вы, прежде чем вы сможете это сделать, поэтому сначала вам нужно зарегистрироваться.

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

Чтобы написать сценарии входа, вам нужно сосредоточиться на двух вещах:

  • написание сценариев
  • реализация определения шага

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

Когда вы пишете сценарии, вы должны сосредоточиться на том, «что» вы делаете и «почему» вы это делаете. Сценарии не должны ничего знать о том, «как» вы что-то делаете. Все, что связано с заполнением материала, нажатием на материал и т. д., является запахом. Когда ваши сценарии имеют дело только с тем, что и почему, они становятся намного проще.

Feature: Registration
  A pre-requistite for signing in, see sign_in.feature

  Scenario: Register
    Given I am a new user
    When I register
    Then I should be registered

Feature: Sign in
  Dependant on registration ...
  I want to sign in so I can have personalised content and ...

  Scenario: Sign in
    Given I am registered 
    When I sign in
    Then I should be signed in

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

Scenario: Sign in with bad password
  Given I am registered
  When I sign in with a bad password
  Then I should not be signed in
  And I should be told ...

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

Вы можете увидеть пример этого на https://github.com/diabolo/cuke_up. Этот пример можно использовать, следуя истории коммитов, и, в частности, обратите внимание на то, как я использую рефакторинг extract_method, чтобы убрать весь код из определений шагов. Каждый метод, который я извлекаю, — это инструмент, который можно повторно использовать при написании последующих сценариев. Создание эффективного набора инструментов — ключ к производительности при реализации сценариев.

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

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

Подводя итог, просто сосредоточьтесь на

  • написание простых сценариев
  • сделать ваши определения шагов элегантными
  • создание инструментов (извлеченных методов), которые можно использовать в следующем написанном вами сценарии.

У вас есть достаточно времени, чтобы изучить другие вещи, и это будет намного проще, если ваша основная механика будет лучше развита.

person diabolist    schedule 01.12.2015
comment
+1 за использование ломающихся игрушек для изучения автоматизации BDD. Однако я все еще опасаюсь использовать логин в качестве сценария в реальном проекте. Большая часть ценности исходит от этого сотрудничества с заинтересованными сторонами и их радостного удивления, когда они видят, что вы не только делаете то, что они просили, но и можете показать, что они всегда будут это делать. Прежде чем писать сценарии, есть шаг, на котором вы обсуждаете сценарии, и он более важен, чем другие шаги. Говорить о логине немного скучно. Используйте что-то другое и интересное в реальном проекте. Но можно использовать логин для практики вне этого. - person Lunivore; 02.12.2015