Использование модульных тестов в качестве «контракта на функциональность» - PullRequest
4 голосов
/ 03 февраля 2009

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

Я собираюсь приступить к проекту, который будет включать доставку прототипов библиотек программного обеспечения для клиентов. Модульные тесты будут поставляться как часть каждого выпуска, и в дополнение к использованию тестов для проверки правильности установки, я планирую использовать модульные тесты, которые тестируют API как «контракт» на то, как следует использовать релиз. Если пользователь использует релиз аналогично тому, как он используется в модульных тестах, тогда замечательно. Если они используют его как-то иначе, все ставки отменены.

Кто-нибудь пробовал это раньше? Есть мысли о том, хорошая это или плохая идея?

Редактировать: Чтобы подчеркнуть хороший момент, поднятый ChrisA и Dan в ответах ниже, «модульные тесты, которые тестируют API» лучше называть интеграционными тестами, и их целью является использование API и программного обеспечения для демонстрации функциональности программное обеспечение с точки зрения клиента.

Ответы [ 8 ]

11 голосов
/ 03 февраля 2009

Звучит как хорошая идея для меня. Я (все мы?) Регулярно использую модульные тесты для этого. Используя мои модульные тесты для проверки того, что я ничего не сломал, я также неявно проверяю, что мой контракт API не изменился. Кажется естественным использование модульных тестов для их развертывания так, как вы говорите.

5 голосов
/ 03 февраля 2009

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

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

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

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

Так что любой юнит-тест прошел бы.

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

Так что теперь у нас есть более простое, сердитое, более подходящее приложение.

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

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

5 голосов
/ 03 февраля 2009

Agile методологии говорят: Тесты - это спецификации , так что это очень хорошая идея.

1 голос
/ 03 февраля 2009

Если вы выпускаете библиотеку кодов , это звучит великолепно.

Если вы выпускаете обычный программный продукт, с которым ваши пользователи будут взаимодействовать только через GUI , ваши модульные тесты могут работать не на том же уровне абстракции или не самый полезный инструмент для оценки поведение вашего продукта. Действительно хорошее руководство пользователя (да, это возможно) может быть лучше для этого.

1 голос
/ 03 февраля 2009

Если вы заинтересованы в предоставлении набора спецификаций для своего кода, возможно, вам следует изучить некоторые инструменты разработки, основанные на поведении (nbehave, jbehave, rspec и т. Д.). Эти платформы предоставляют поддержку для описания ваших тестов в заданном / когда / затем синтаксисе и вывода форматированных результатов на естественном языке. См. nbehave для примера инструмента BDD для .NET. Вы можете найти отличное описание BDD здесь

Другим вариантом может быть написание тестов с использованием среды приемочного тестирования, такой как fit или fitnesse (или java-only concordion ) и доставка эти приемочные испытания с кодом. И fit / fitnesse, и concordion позволяют указывать тесты в простом HTML или даже в документах Word.

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

1 голос
/ 03 февраля 2009

На самом деле это довольно хорошая идея, и она чрезвычайно приятна для пользователя API.

Эту технику на самом деле можно использовать и наоборот: когда вы используете «устаревший» API, вы можете использовать модульные тесты для документирования того, как вы думаете, как работает API, и для проверки того, что он действительно ведет себя как запланировано.

0 голосов
/ 03 февраля 2009

Месарош называет это "Тесты как документация"

0 голосов
/ 03 февраля 2009

Тесты проверит требования.

Требования определяют функциональность

=> Тесты проверят работоспособность.

Проблема в том, что можно проверить только функциональность, которая может быть охвачена модульными тестами. Интеграционные или целые системные тесты не будут работать.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...