Как я могу протестировать управляемую оболочку вокруг кода C?

Question

Я буду создавать оболочку Managed-C ++ для некоторых функций C, чтобы разрешить ее использование в других .NET-решениях. Я смотрю на предоставление очень минималистской обертки, что-то вроде:

Подпись в заголовке C:

void DOSTH(const char*, short, long*);

Открытый управляемый интерфейс:

public void doSomething(String^ input, short param, [Out] long^ %result);

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

Будучи новичком в Visual Studio, я не уверен, как бы выполнить это модульное тестирование. Можно ли макет .dll, чтобы обеспечить ложную реализацию? Есть ли библиотека, которая облегчила бы задачу такого рода? Есть ли конкретная структура решения, к которой я должен стремиться, чтобы сделать это проще?

Любое руководство в этой области было бы замечательно. Поиски в Google оставили меня в поисках дополнительной информации о модульном тестировании управляемой оболочки.

Answer 1

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

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

Создайте простую, фальшивую реализацию (почти как заглушку, например, возвращающую только фиксированные значения независимо от входных параметров - естественно, может быть более изощренной).чем это), скомпилируйте его, позвольте ему выставлять точно такие же заголовки / функции и ссылайтесь на него в вашем тестовом проекте.Это основная идея подделки (заглушки / насмешки) - один объект притворяется другим.

Как бы просто это не звучало, я даже не пробовал этого - взять его с крошкойсоли и многое другое, как предложение, по которому вы могли бы пойти.Ограничение этого подхода (помимо того, действительно ли это технически возможно) составляет очень плохие / нет параметров конфигурации (поскольку дополнительная фальсифицированная DLL будет действовать как жестко закодированный заглушка - файлы конфигурации могут помочь, но это похоже... слишком много работы?).

Answer 2

Вам нужно только иметь возможность заглушить / смоделировать вашу обертку, чтобы ваши тесты не полагались на нативный dll?

Затем вы можете объявить абстрактный базовый класс для вашей обертки, написать одну реализацию, которая вызывает нативный dll, и другую для целей тестирования, которая возвращает готовые значения. Или вы можете использовать фреймворк, такой как Moq или Rhino.Mocks , чтобы высмеивать вашу обертку.