Структура тестирования BDD - PullRequest
3 голосов
/ 15 апреля 2011

Мы - магазин Microsoft, у нас достаточно развит технологический стек и очень опытные ресурсы .net. Мы использовали TDD с самого начала и теперь углубляемся в пространство BDD. Наша работа выполняется гибкими командами с использованием сильных гибких практик.

Нашим конечным тестируемым продуктом являются веб-формы, wpf и windows-формы.

Ресурсы по тестированию внедрили BDD и хотели бы изучить и использовать Ruby и Cucumber для выполнения тестирования. Разработчики оказали некоторое сопротивление, поскольку мы предпочли бы придерживаться одного и того же технологического стека и использовать Specflow (или аналогичный). Аргумент от тестировщиков заключается в том, что учиться проще.

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

Ответы [ 3 ]

4 голосов
/ 15 апреля 2011

Как SpecFlow, так и Cucumber используют один и тот же язык, понятный деловому человеку ( герхин ), чтобы указать функции;единственная разница в том, будете ли вы писать определения шагов в C # (используя, например, WatiN для запуска тестов на основе браузера) или Ruby (используя, например, Watir).Таким образом, тесты будут структурированы очень схожим образом и дадут одинаковые преимущества независимо от того, какой из них вы выберете.

Я предполагаю, что преимущество использования SpecFlow над Cucumber заключается в том, что тесты будут легко запускаться из Visual Studioа также, например, из TeamCity или других инструментов непрерывной интеграции на основе .NET.С другой стороны, когда тесты Cucumber изменяются или добавляются новые тесты, вам не нужно ждать перекомпиляции (однако изменение в коде теста часто сопровождается изменением в рабочем коде, так что это, вероятно, выиграет 'Это значительная экономия).Когда дело доходит до тестирования приложений на основе WPF или Windows Forms, я предполагаю, что будет проще управлять этими приложениями из .NET (но может быть, что есть некоторая библиотека Ruby для управления другими приложениями с графическим интерфейсом ...)

2 голосов
/ 27 апреля 2011

У нас похожая настройка, у нас есть тестеры, которые пишут и реализуют шаги за сценариями.Наши тестеры очень довольны пребыванием с .net и c #.Я думаю, что если вы представите другую технологию, разработчики не будут запускать тесты до их фиксации и не будут нести ответственность за тесты, если они не пройдут, поскольку отладку будет крайне сложно.Это будет означать, что ваша сборка будет сломана больше, чем она работает.

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

1 голос
/ 17 декабря 2011

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

http://codingcraft.wordpress.com/2011/12/17/bdd-with-specflow

BDD может заставить вас сделать ваш TDD правильно.

...