Дизайн контракта и [закрытая] разработка через тестирование

Я добавил бы:

API является контрактом для программистов, определением UI является контракт с клиентами, протокол является контрактом для взаимодействий клиент-сервер. Получите тех сначала, тогда можно использовать в своих интересах параллельные дорожки разработки и не заблудиться в сорняках. Да, периодически рассматривайте, чтобы удостовериться, что требованиям отвечают, но никогда не запускают новый трек без контракта. И 'контракт' является сильным словом: после того, как развернутый, это никогда не должно изменяться. Необходимо включать управление управлением версиями и самоанализ с самого начала, изменения в контракте только реализованы дополнительными наборами, изменением номеров версий с ними, и затем можно сделать вещи как постепенное ухудшение при контакте со смешанными или старыми установками.

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

я - немного подозрительного дизайна TLA. Как с Шаблонами, модное словечко совместимые рецепты являются хорошим руководством, но именно моим опытом нет такой вещи как единая процедура управления проектированием или управления проектами. При выполнении вещей точно Книгой (TM) тогда если это не будет контракт DOD с DOD процедурные требования, Вы, вероятно, попадете в беду где-нибудь по пути. Прочитайте Книгу (книги), да, но убедитесь tounderstand их, и затем примите во внимание также людей сторона Вашей команды. Правила, которые только осуществляются Книгой, не будут осуществлены однородно - даже когда осуществлено инструментом могут быть выпадения сигнала (например, комментарии svn оставили пустым или тайно кратким). Процедуры только имеют тенденцию быть выполненными, когда набор инструментальных средств не только осуществляет их, но и делает после более легкого, чем какие-либо возможные ярлыки. Верьте мне, когда движение жестко ведет себя, ярлыки найдены, и Вы не можете знать о тех, которые привыкли в 3:00, пока не слишком поздно.

Microsoft сделала работу над автоматической генерацией модульных тестов, на основе контрактов кода и параметризовала модульный тест. Например, в контракте говорится, что количество должно быть увеличено тем, когда объект добавляется к набору, и параметризованный модульный тест говорит, как добавить объекты “n” к набору. Pex тогда попытается создать модульный тест, который доказывает, что условия контракта нарушены. Посмотрите этот видео для обзора.

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

Я думаю, что существует перекрытие между DbC и TDD, однако, я не думаю, там дублирован работа: представление DbC, вероятно, приведет к сокращению тестовых сценариев.

Позволяют мне объяснить.

В TDD, тесты не являются действительно тестами. Они - поведенческие спецификации. Однако они также средства проектирования: путем записи теста сначала, Вы используете внешний API своего объекта под test †“, что Вы на самом деле не записали yet †“таким же образом, что пользователь был бы. Тем путем Вы разрабатываете API способом, который имеет смысл пользователю, а не в пути, который делает самым легким для Вас реализовать. Что-то как queue.full? вместо queue.num_entries == queue.size.

Эта вторая часть не может быть заменена Контрактами.

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

, Но контракты зафиксировали гранулярность: у Вас есть метод пред - и постусловия, объектные инварианты, контракты модуля и так далее. Возможно, варианты цикла и инварианты. Модульные тесты однако, тестовые единицы поведения. Те могли бы быть меньшими, чем метод или состоять из нескольких методов. Это не что-то, что можно сделать с контрактами. И для "большого изображения" Вам все еще нужны интеграционные тесты, функциональные испытания и приемочные испытания.

И существует другая важная часть TDD, который не покрывает DbC: середина D. В TDD, тесты диск Ваш процесс разработки: Вы никогда не пишете одну строку кода реализации, если у Вас нет провального теста, Вы никогда не пишете одну строку тестового кода, если Ваши тесты вся передача, Вы только не пишете минимальную сумму кода реализации для создания тестовой передачи, Вы только пишете минимальную сумму тестового кода для создания провального теста.

В заключении: используйте тесты для разработки "потока", "чувства" API. Используйте контракты для разработки, ну, в общем, контракт API. Используйте тесты для обеспечения "ритма" для процесса разработки.

Что-то вроде этого:

1. Запись приемочное испытание для функции
2. Запись модульный тест на единицу, которая реализует часть той функции
3. Используя сигнатуру метода, которую Вы разработали на шаге 2, запишите, что прототип метода
4. Добавляет, что постусловие
5. Добавляет Реализацию предварительного условия
6. тело метода
7. , Если приемочное испытание передает, goto 1, иначе goto 2

, Если Вы хотите знать то, что Bertrand Meyer, изобретатель Дизайна Контракта, думает об объединяющемся TDD, и DbC, существует хорошая статья его группы, названной Управляемый Контрактом Дизайн = Разработка через тестирование - Пишущий Тесты . Основная предпосылка - то, что контракты предоставляют абстрактное представление всех возможных случаев, тогда как тестовые сценарии только тестируют конкретные случаи. Поэтому подходящая тестовая обвязка может быть автоматически сгенерирована из контрактов.

Можно также использовать исполняемые приемочные испытания, которые записаны на доменном языке контракта. Это не мог бы быть фактический "контракт", но половина пути между модульными тестами и контрактом.

я повторно прокомментировал бы использование Огурец Ruby http://github.com/aslakhellesoy/cucumber

, Но так как Вы - магазин Perl, тогда возможно, можно использовать мою собственную маленькую попытку p5-огурца. http://github.com/kesor/p5-cucumber

Некоторое время назад у меня были некоторые размышления на эту тему.

Вы можете взглянуть на

http://gleichmann.wordpress.com/2007/12/09 / test-driven-development-and-design-by-contract-friend-or-foe /