Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО

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

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

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

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

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

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

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

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

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) – это всего лишь служебный код, который необходимо написать для связывания тестов с тестируемой системой. Достаточно сказать, что все перечисленные инструменты предоставляют те или иные средства поиска по шаблону для распознавания и разбора инструкций теста и последующего вызова функций, передающих данные тестируемой системе. Все это делается достаточно просто, а полученные сценарии и оснастки могут использоваться в разных тестах.

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

Авторы тестов – люди, и они тоже допускают ошибки. Иногда при переходе к реализации становится очевидно, что тест выглядит бессмысленно. Тесты бывают слишком запутанными или громоздкими.

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

Ваша задача как профессионального разработчика – обсудить ситуацию с автором теста для его улучшения. Никогда не выбирайте пассивно-агрессивную позицию, когда вы говорите себе: «Как написано в тесте, так я и сделаю».

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