Limitaciones del uso de C++/CLI con NUnit

Question

This answer a una pregunta sobre los marcos de prueba de unidades C++ sugiere una posibilidad que no se me había ocurrido antes: usar C++/CLI y NUnit para crear pruebas unitarias para código C++ nativo.

Utilizamos NUnit para nuestras pruebas de C#, por lo que la posibilidad de usarlo para C++ también parece tentador.

Nunca he usado C++ administrado, entonces mi preocupación es ¿hay limitaciones prácticas para este enfoque? ¿Muchos de ustedes están haciendo esto? Si es así, ¿cómo fue tu experiencia?

Answer 1

Hacemos esto todo el tiempo. Tenemos muchos ensamblajes escritos con C++/CLI y usamos C# y NUnit para probarlos. En realidad, dado que nuestro objetivo es proporcionar ensamblajes que funcionen bien con C#, hacer esto asegura que lo hayamos logrado.

También puede escribir pruebas NUnit en C++/CLI y llamar a C++ no administrado. Probablemente la mejor manera es mantener su C++ puro no administrado en una lib, y luego hacer un ensamblaje de prueba que use NUnit y enlaces a la lib.

Answer 2

Nunca he usado uno, pero ¿no hay un puerto? Tal vez http://cunit.sourceforge.net/documentation.html funcionaría para usted.

Answer 3

Funciona muy bien y le da la ventaja de tener pruebas parametrizadas, así como un corrector de prueba común y el marco si se encuentra en un entorno mixto.

Hay dos inconvenientes, ninguno de los cuales es grave para la mayoría de los casos:

1. Si estás siendo realmente exigente, las pruebas ya no están en ejecución en un entorno puramente nativa por lo que hay una posibilidad fuera que algo puede funcionar bajo prueba pero falla en tiempo de ejecución. Creo que tendrías que estar haciendo algo bastante exótico para que esto importe.

2. Confía en que su código C++ pueda incluirse en un programa C++/CLI. A veces, esto puede tener conflictos con los encabezados y obliga a tu código a compilar OK con UNICODE. En general, esto es algo bueno ya que descubre fragmentos de código crudos (como el uso inconsistente de variantes Ansi de llamadas Win32). Tenga en cuenta que solo se incluyen los encabezados, por lo que lo que puede mostrar es que está exponiendo los encabezados a un nivel demasiado alto; algunos de sus elementos incluidos deberían estar dentro de sus archivos de implementación de cpp.

Answer 4

La mayor preocupación es la curva de aprendizaje del lenguaje C++/CLI (antes de C++) en sí, si las pruebas deben ser entendidos o mantenido por los desarrolladores de los no-C++.

Se necesita un mínimo de 1-2 años de experiencia C++ OOP para poder realizar contribuciones en un proyecto de prueba C++ CLI/NUnit y para resolver los diversos problemas que surgen entre las interfaces de código administrado nativo . (Por contribución, me refiero a poder trabajar de forma autónoma y poder crear objetos simulados, implementar y consumir interfaces nativas en C++/CLI, etc. para satisfacer todas las necesidades de prueba).

Algunas personas nunca pueden comprender C++/CLI lo suficientemente bueno como para poder contribuir. Para ciertos tipos de bibliotecas de software nativas con necesidades de prueba muy exigentes, C++/CLI/NUnit es la única combinación que satisfará todas las necesidades de pruebas de la unidad, manteniendo el código de prueba ágil y capaz de responder a los cambios. Recomiendo el libro xUnit Test Patterns: Refactoring Test Code para ir en esta dirección.

Answer 5

Mi experiencia es que no es posible usar NUnit para probar el código nativo de C++ a través de C++/CLI porque tendrá problemas para cargar y usar código nativo.

He intentado utilizar nunit para cargar un dll de prueba C++/cli básico vinculado contra "solo el hilo" que es una implementación de la biblioteca de hilos estándar de C++. Los DLL de prueba ni siquiera se cargarán con la última versión de NUnit (2.6.2).

¡Definitivamente no es el camino a seguir!