Ограничения использования C ++ / CLI с NUnit

Question

Этот ответ на вопрос об инфраструктурах модульных тестов C ++ предполагает возможность, которой я раньше не видел: использование C ++ / CLI и NUnit для создания модульных тестов для собственного кода C ++.

Мы используем NUnit для наших тестов на C #, поэтому возможность использования его для C ++ также выглядит заманчиво.

Я никогда не использовал управляемый C ++, поэтому меня беспокоит, есть ли практические ограничения для этого подхода? Многие из вас делают это? Если да, то каким был твой опыт?

Answer 1

Мы делаем это постоянно. У нас есть много сборок, написанных на C ++ / CLI, и мы используем C # и NUnit для их тестирования. На самом деле, поскольку наша цель - предоставить сборки, которые хорошо работают с C #, выполнение этого гарантирует, что мы достигли этого.

Вы также можете писать тесты NUnit в C ++ / CLI и вызывать неуправляемый C ++. Вероятно, лучший способ - сохранить ваш чистый неуправляемый C ++ в библиотеке, а затем создать тестовую сборку, которая использует NUnit и ссылки на библиотеку.

Answer 2

Мой опыт показывает, что невозможно использовать NUnit для тестирования собственного кода C ++ через C ++ / CLI, потому что у вас будут проблемы с загрузкой и использованием собственного кода.

Я пытался использовать nunit для загрузки базового dll-теста c ++ / cli, связанного с «just thread», который является реализацией стандартной библиотеки потоков c ++. Тестовые библиотеки даже не загружаются с последней версией NUnit (2.6.2).

Так что определенно не путь!

Answer 3

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

Есть два недостатка, ни один из которых не является серьезным в большинстве случаев:

1. Если вы действительно требовательны, тесты больше не выполняются в чисто естественной среде, поэтому существует внешняя вероятность того, что что-то может работать при тестировании, но не работать во время выполнения. Я думаю, тебе нужно сделать что-то довольно экзотическое, чтобы это имело значение.

2. Вы полагаетесь на то, что ваш код C ++ может быть включен в программу C ++ / CLI. Иногда это может привести к конфликтам с заголовками, и это заставит ваш код нормально работать с UNICODE. В целом, это хорошо, так как раскрывает грубые фрагменты кода (например, непоследовательное использование вариантов вызовов Win32 Ansi). Имейте в виду, что включаются только заголовки, поэтому может показаться, что вы выставляете заголовки на слишком высоком уровне - некоторые из ваших включений, вероятно, должны быть в ваших файлах реализации cpp.

Answer 4

Самое большое беспокойство вызывает кривая обучения самого языка C ++ / CLI (ранее Managed C ++), если тесты должны быть поняты или поддерживаться разработчиками не на C ++.

Требуется минимум 1-2 года опыта работы с C ++ ООП, чтобы иметь возможность внести вклад в тестовый проект CLI / NUnit на C ++ и решить различные проблемы, возникающие между интерфейсами управляемого кода. (Под вкладом я имею в виду возможность работать автономно и создавать фиктивные объекты, реализовывать и использовать собственные интерфейсы в C ++ / CLI и т. Д. Для удовлетворения всех потребностей тестирования.)

Некоторые люди могут просто не понять C ++ / CLI достаточно хорошо, чтобы иметь возможность внести свой вклад.

Для некоторых типов собственных программных библиотек с очень высокими требованиями к тестированию C ++ / CLI / NUnit является единственной комбинацией, которая будет отвечать всем потребностям модульного тестирования, сохраняя тестовый код гибким и способным реагировать на изменения. Я рекомендую книгу xUnit Test Patterns: рефакторинг тестового кода , чтобы идти в этом направлении.

Answer 5

Я никогда не использовал один, но разве нет порта? Возможно, http://cunit.sourceforge.net/documentation.html подойдет вам.