Ограничения использования 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

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

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

<Ол>

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

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