Роль разработчика

Роль разработчика

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

Пола: «Питер, поможешь мне?»

Питер: «Разумеется, а что случилось?»

Пола: «Вот наш приемочный тест. Как видишь, он не проходит».

given the command LogFileDirectoryStartupCommand

given that the old_inactive_logs directory does not exist

when the command is executed

then the old_inactive_logs directory should exist and it should be empty[35]

Питер: «Да, все результаты красные. Ни один сценарий еще не написан. Давай я напишу первый»:

|scenario|given the command _|cmd|

|create command|@cmd|

Пола: «А у нас уже есть операция createCommand»?

Питер: «Да, в пакете CommandUtilitiesFixture, который я написал на прошлой неделе».

Пола: «Хорошо, давай запустим тест».

Питер: (запускает тест) «Первая строка стала зеленой, переходим к следу ющей».

Не обращайте внимания на все эти сценарии (scenarios) и оснастки (fixtures) – это всего лишь служебный код, который необходимо написать для связывания тестов с тестируемой системой. Достаточно сказать, что все перечисленные инструменты предоставляют те или иные средства поиска по шаблону для распознавания и разбора инструкций теста и последующего вызова функций, передающих данные тестируемой системе. Все это делается достаточно просто, а полученные сценарии и оснастки могут использоваться в разных тестах.

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

Данный текст является ознакомительным фрагментом.