Рекомендации по тестированию модулей на API сторонних разработчиков (AutoCAD)

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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