Должны ли мои модульные тесты напрямую касаться API при тестировании оболочки для этого API?

Question

У меня есть несколько написанных модульных тестов, которые проверяют обертку вокруг API сервера FTP .

И модульные тесты, и FTP-сервер находятся на одном компьютере.

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

В модульном тесте, скажем, для добавления пользователя в виртуальный домен, я создаю сообщение XML для отправки в API. API выполняет свою работу и возвращает ответ с информацией о состоянии о том, была ли операция успешной или неудачной (коды ошибок, ошибки проверки и т. Д.).

Чтобы проверить, действительно ли код API-оболочки действительно действовал правильно (если ответ показал успешность), я вызываю COM-интерфейс FTP-сервера и напрямую запрашиваю его хранилище, чтобы выяснить, например, при создании учетной записи пользователя аккаунт действительно создан.

Это плохо пахнет?

Обновление 1: @ Джереми / Ник: Оболочка находится в центре внимания тестирования, FTP-сервер и его COM API являются продуктами сторонних производителей, предположительно хорошо протестированными и стабильными. API-оболочка должна проанализировать сообщение XML и затем вызвать API-интерфейс FTP-сервера. Как бы я проверил, и это может быть глупым случаем, что определенное свойство учетной записи пользователя правильно установлено оболочкой. Например, установка неправильного свойства или атрибута учетной записи FTP из-за опечатки в коде оболочки. Хорошим примером является установка пределов скорости загрузки и выгрузки, которые могут быть перенесены в код оболочки.

Обновление 2: спасибо всем за ответы. Людям, которые предлагали использовать макеты, это пришло мне в голову, но свет там еще не включился, и я все еще пытаюсь понять, как заставить свою оболочку работать с макетом FTP-сервера. , Где будут находиться макеты, и я могу передать экземпляр указанных макетов в API-оболочку, чтобы использовать вместо вызова COM API? Я знаю о насмешках, но изо всех сил пытаюсь разобраться в этом, в основном потому, что я нахожу, что большинство примеров и учебных пособий настолько абстрактны и (стыдно сказать) граничат с непостижимым.

Answer 1

Вы, похоже, испытываете проблемы с тестированием компонентов и компонентов.

• Если вы проводите модульное тестирование своей обертки, вам следует использовать фиктивный FTP-сервер и не задействовать реальный сервер. Плюсом является то, что вы можете достичь 100% автоматизации, как это.
• Если вы тестируете компоненты целиком (оболочка + сервер FTP работают вместе), попробуйте проверить свои результаты на том же уровне, что и ваши тесты, то есть с помощью API-оболочки. Например, если вы вводите команду для загрузки файла, затем введите команду для удаления / загрузки этого файла, чтобы убедиться, что файл был загружен правильно. Для более сложных операций, когда тестирование результата не является тривиальным, подумайте о том, чтобы прибегнуть к упомянутому вами «бэкдору» COM API или, возможно, потребовать некоторой ручной проверки (все ваши тесты должны быть автоматизированы?).

Answer 2

Чтобы проверить вашу обертку с фиктивным объектом, вы можете сделать следующее:

• Напишите объект COM, который имеет тот же интерфейс, что и интерфейс COM API сервера FTP. Это будет ваш фиктивный объект. Вы должны иметь возможность обмениваться реальным FTP-сервером и вашим фиктивным объектом, передавая указатель интерфейса любого из них в оболочку посредством внедрения зависимостей.
• Ваш фиктивный объект должен реализовывать жестко запрограммированное поведение на основе методов, вызываемых в его интерфейсе (имитирующем API-интерфейс FTP-сервера), а также на основе используемых значений аргумента:
• Например, если у вас есть метод UploadFile, вы можете вслепую вернуть результат успеха и, возможно, сохранить переданное имя файла в виде массива строк.
• Вы можете смоделировать ошибку загрузки при обнаружении имени файла с ошибкой.
• Вы можете смоделировать задержку / тайм-аут, когда вы встретите имя файла с "slow" в нем.
• Позже, метод DownloadFile может проверять внутренний строковый массив, чтобы определить, был ли уже загружен файл с таким именем.

Псевдокод для некоторых тестовых случаев будет:

//RealServer theRealServer;
//FtpServerIntf ftpServerIntf = theRealServer.getInterface();

// Let's test with our mock instead
MockServer myMockServer;
FtpServerIntf ftpServerIntf = myMockServer.getInterface();

FtpWrapper myWrapper(ftpServerIntf);

FtpResponse resp = myWrapper.uploadFile("Testing123");
assertEquals(FtpResponse::OK, resp);

resp = myWrapper.downloadFile("Testing123");
assertEquals(FtpResponse::OK, resp);

resp = myWrapper.downloadFile("Testing456");
assertEquals(FtpResponse::NOT_FOUND, resp);

resp = myWrapper.downloadFile("SimulateError");
assertEquals(FtpResponse::ERROR, resp);

Надеюсь, это поможет ...

Answer 3

Чтобы проверить, действительно ли код обертки API действовал правильно (если ответ показал успех), я вызываю COM API FTP-сервера

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

Если ваш тест запускает как оболочку, так и FTP-сервер, вы не являетесь модульным тестом.

Answer 4

Я согласен с Ником и Джереми в том, что они не касаются API. Я бы посмотрел на издевательство над API.

http://en.wikipedia.org/wiki/Mock_object

Если это .NET, вы можете использовать:
Мок: http://code.google.com/p/moq/

И куча других насмешливых библиотек.

Answer 5

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

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

Answer 6

Не похоже, что вы спрашиваете "Должен ли я проверить API?" - вы спрашиваете: «Должен ли я использовать API, чтобы проверить, правильно ли работает мой упаковщик?»

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

Answer 7

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

Answer 8

Что вы тестируете оболочку или API. API должен работать как есть, поэтому я не думаю, что вам нужно его тестировать. Сосредоточьте свои усилия на тестировании на оболочке и сделайте вид, что API не существует, когда я пишу класс, который осуществляет доступ к файлам, я не тестирую модуль в сборке в потоковом считывателе ... Я сосредотачиваюсь на своем коде.