Лучшие практики с модульным тестированием на сторонних программных API (AutoCAD)

Question

Мы разрабатываем приложения для использования в AutoCAD. По сути, мы создаем проект библиотеки классов и загружаем .dll в autoCAD с помощью команды (NETLOAD).

Таким образом, мы можем использовать команды, «палитры», пользовательские элементы управления, формы и т. Д ...

AutoDesk предоставляет API через некоторые библиотеки DLL, работающие в каталоге их программ. При обращении к этим dll вы можете вызывать dll только во время выполнения, загружая ваше приложение в AutoCAD (это защита лицензирования от AutoDesk).

Для нас, при разработке, это не проблема, нам нужно визуально протестировать в контексте AutoCAD, поэтому мы просто устанавливаем свойства отладки, чтобы они запускали acad.exe и загружали нашу dll со скриптом в acad .exe параметры.

Проблема в том, что при попытке модульного тестирования нашего кода NUnit или mstest не запускаются из контекста AutoCAD и также не могут его запустить. Существует инструмент под названием Gallio, который предоставил интерфейс с AutoCAD, чтобы он мог запускать модульное тестирование через IPC с именованными каналами.

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

Итак, что из "хорошего дизайна" было бы хорошим подходом к этой проблеме? Я думаю, что в основном мне понадобится тестируемая кодовая база, которая не ссылается на DLL-файлы AutoCAD, а не тестируемая, которая действительно ссылается на не тестируемые DLL-файлы AutoCAD.

Я уверен, что есть способы заставить это работать: (IOC, DI, Adapter Pattern, ...). Я просто глубоко не разбираюсь в этих принципах и поэтому не знаю, какой маршрут лучше всего подойдет для моих целей. и цели.

Answer 1

Первым шагом является сортировка кода для деталей, для которых требуется AutoCAD, и деталей, которые действительно независимы. Создайте модульные тесты для независимых частей, как обычно.

Для других частей вам нужны макеты, которые ведут себя как AutoCAD. Сделайте их максимально простыми (например, просто верните правильные ответы в методах без каких-либо вычислений). Теперь вам нужно несколько наборов классов:

1. Набор интерфейсов, которые ваш код использует для достижения чего-либо (например, загрузки чертежа).

2. Набор реализаций для указанного набора интерфейсов, которые вызывают библиотеки AutoCAD.

3. Набор классов, которые пробуют реализации в контексте AutoCAD. Просто создайте небольшой интерфейс с парой кнопок, чтобы вы могли запустить этот код. Он используется, чтобы убедиться, что ваши макеты делают правильные вещи. Запишите параметры метода и результаты в некоторый файл, чтобы вы могли попробовать, как AutoCAD отвечает. Если макет не работает, вы можете использовать этот код, чтобы проверить, что делает AutoCAD, и использовать его в качестве справочного материала при разработке макетов.

4. Когда вы знаете, как реагирует AutoCAD, создайте макеты. В своих тестах создайте их с желаемыми результатами (и ошибками, чтобы вы также могли проверить обработку ошибок). Поэтому, когда у вас есть boolean loadDrawing(File filename), создайте макет, который возвращает true для имени файла exists.dxf и false для всего остального.

5. Используйте фабрику или DI, чтобы сообщить коду своего приложения, какую реализацию использовать. У меня, как правило, большой глобальный конфигурационный класс с множеством открытых полей, в которых я просто храню объекты для использования. Я могу настроить это в начале, это быстро, это легко понять. Если вам нужно создавать объекты во время выполнения, поместите фабрики в класс config, которые будут генерировать объекты для вас, чтобы вы могли их поменять.

Answer 2

Я написал ... и позже сломал ... Тестовый бегун для AutoCAD. Это на https://github.com/CADbloke/CADtest. Если вы заинтересованы в этом, подтолкните меня, и я исправлю это быстрее. Я жду релиза NUnit v3, прежде чем заняться им.

Если вы восстановите 3-й коммит в этом репо (я думаю) и возьмете его оттуда, он должен запуститься.