актуальность и польза от насмешливой среды для эмуляции различных физических устройств

Question

Является ли фреймворк-фреймворк хорошей идеей для работы с несколькими физическими устройствами и их дразнить?

Основная цель моей компании - связать наше программное обеспечение с театральным проектором нескольких марок (barco, sony ...), звуковым процессором, контроллером ввода-вывода (barionet, wago).

Иногда поставщик предоставляет API для связи, иногда это делается с помощью сокета, иногда это действительно «зависит от поставщика»

До сих пор вот наша методология:

- если это просто: напишите фиктивный класс «devicexxxMock», который слушает заказ, и отвечает «да» на каждый вопрос - использование эфириала или геркулеса - Если это действительно необходимо: написание эмулятора (аналогично первому способу, но ответьте да или нет, зависит от того, что мы хотим протестировать)

Мы ищем последовательный способ тестирования нашего кода без использования реальных устройств. И не теряя времени на написание эмулятора.

Редактировать: Мы разговариваем с 4 типами устройств:

Большинство устройств, с которыми мы должны общаться, отвечают в байтовом массиве в сокете. некоторые используют SNMP Некоторые из них с поддержкой HTTP (http://ip/commandToExecute) У некоторых есть API в Java

Answer 1

Черт, да. Я думаю, что это идеальное место для насмешливых рамок. Просто создайте интерфейсный слой, который отделяет аппаратное (или аппаратное API) от кода, который его контролирует ... IProjector, ISoundProcessor и т. Д.

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

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

Answer 2

Как предполагает Брайан Дженизио, это звучит как идеальный кандидат для насмешек, и его аргументы в пользу насмешек против подделок очень убедительны. Я не использовал mocks для тестирования взаимодействия с оборудованием, но я использовал их для тестирования взаимодействия с сторонними собственными API, предоставляемыми поставщиками, что очень похоже на случай использования. Общий шаблон: - иметь интерфейс, который выводит объект, представляющий ввод, произведенный нативным API (или аппаратным устройством в вашем случае) - смоделируйте его, чтобы получить входные данные, необходимые для вашего теста - утверждаем, что ваш код правильно обрабатывает этот ввод

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

Я пишу на Java, используя JUnit для своей среды тестирования, и использую EasyMock (http://easymock.org) и JMock (http://www.jmock.org).). Я предпочитаю (и в настоящее время использую) JMock, но стоит попробовать оба варианта как свои философии довольно разные. Я также слышал, что Мокито (http://mockito.org) очень хорош, но на самом деле не использовал его в гневе.

Answer 3

Компания под названием Atomic Object имеет несколько хороших отчетов об использовании Mock Objects в C при работе со встроенными устройствами. См. Документы на http://www.atomicobject.com/pages/Papers

Answer 4

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

Answer 5

Заменить "да" на self.Responder.Next(). Передайте экземпляр класса (в зависимости от вашего языка), Responder конструктору вашего издателя. Тривиальная реализация Next - это return "yes";, но вы также можете заставить ее возвращать другие вещи, в зависимости от того, как она была построена. Фактические детали этой техники будут различаться в зависимости от того, на каком языке написан издеватель.