Имеет ли смысл использовать TDD для кода библиотеки / API и BDD в качестве интеграционных тестов? - PullRequest
Новая
       28

Имеет ли смысл использовать TDD для кода библиотеки / API и BDD в качестве интеграционных тестов?

5 голосов
/ 04 ноября 2010

Я - новичок в BDD, и я хотел бы понять, где он вступает в игру в цикле разработки. В подходах TDD мы обычно пишем юнит-тесты для библиотек или API, мы имитируем объекты, и это было здорово, потому что это могло даже управлять нашим дизайном. Эти тесты будут написаны перед фактическим кодом, который хорош.

Я понимаю, что BDD больше относится к тестированию спецификаций / сценариев, и я вижу, что он идеально подходит для проверки бизнес-требований на соответствие реальному коду. Но как лучше всего писать эти тесты? Продолжаем ли мы писать отдельные тесты (как в TDD), проверяя зависимости и писать юнит-тесты для каждой вещи, которая может пойти не так? Тогда напишите наши тесты BDD? Пишем ли мы сначала bdd тесты? Мы пишем только bdd тесты даже для отдельных компонентов?

Я использую .NET и обычно пишу приложения asp.net mvc, но это скорее вопрос теории и не зависит от языка программирования.

Большое спасибо.

Ответы [ 3 ]

6 голосов
/ 04 ноября 2010

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

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

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

Всякий раз, когда мне нужно реализовать метод реального класса, я использую TDD для тщательного тестирования.

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

1 голос
/ 05 ноября 2010

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

Мы используем диалоговые шаблоны, такие как «Учитывая контекст, когда происходит это событие, тогда этот результат должен происходить», и поощряем такие вопросы, как «Должно ли это быть? Всегда? Есть ли какие-либо другие контексты, которые мы пропускаем?»

Мы можем сделать это на уровне объекта, на уровне сценария или даже в пространстве анализа.

Я стремлюсь работать с самого высокого уровня внутрь. Вот статья, которую я написал , в которой описывается, как это выглядит, прямо от видения проекта до модульных тестов.

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

Затем я начну с пользовательского интерфейса.Это может быть графический интерфейс, веб-страница или интерфейс другой системы для использования моей системы.Когда это будет сделано, я смогу узнать, нравится ли это моим пользователям.Я часто кодирую данные и т. Д., Просто чтобы получить эту обратную связь.

Когда я примерно знаю, как будет выглядеть мой графический интерфейс, я могу начать создавать поведение, стоящее за ним.Я обычно начинаю с поведения контроллера.Я напишу примеры на уровне класса, которые описывают поведение и обязанности класса.Я использую издевательства вместо сотрудничающих классов, которые я еще не написал.Это эквивалент TDD, но вместо того, чтобы писать тесты, которые закрепляют код так, чтобы никто не сломал его, я пишу примеры того, как вы можете использовать мой код, которые показывают, как он ведет себя и почему он ценен, чтобы вы могли изменитьэто безопасно.Я также использую Given / When / Then для этого!Но я склонен использовать более технический язык и не беспокоиться о том, что он читается на английском.Часто мои данные / когда / только в комментариях. Вот пример поведения класса из той же кодовой базы, что и сценарии, так что вы можете увидеть, в чем разница.

Надеюсь, это поможет, и удачи с BDD!

0 голосов
/ 04 ноября 2010

Вы можете использовать его так же, как TDD, модульное тестирование или другое.Разница придет от тестирования "Делового поведения".Spec Flow and Features - это один из вариантов, синтаксис модульного тестирования будет выглядеть примерно так: 

[Given(@"a user exists with username ""(.*)"" and password ""(.*)""")]
public void GivenAUserExistsWithUsernameAdminAndPasswordPassword(string userName, string password) {

}

[Then(@"that user should be able to login using ""(.*)"" and ""(.*)""")]
public void ThenThatUserShouldBeAbleToLoginUsingAdminAndPassword(string userName, string password) {
        Assert.IsTrue(_authService.IsValidLogin(userName, password));
    }
...