Использование модульных тестов в качестве «договора о функциональности»

Question

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

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

Пробовал ли кто-нибудь раньше? Любые мысли о том, является ли это хорошей/плохой идеей?

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

Answer 1

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

Answer 2

Гибкие методологии говорят: Испытания являются спецификациями, поэтому это очень хорошая идея.

Answer 3

Это на самом деле довольно хорошая идея и очень приятная, как пользователь API.

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

Answer 4

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

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

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

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

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

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

Итак, теперь у нас есть более компактное, более плотное приложение для слесарей.

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

Испытания будут проверять требования.

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

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

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

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

Answer 8

Meszaros называет это «Тесты как документация»