Limitaciones del uso de C ++ / CLI con NUnit

Question

Esta respuesta a una pregunta sobre marcos de prueba de unidad de C ++ sugiere una posibilidad eso no se me había ocurrido antes: usar C ++ / CLI y NUnit para crear pruebas unitarias para el código C ++ nativo.

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

Nunca he usado C ++ administrado, por lo que mi preocupación es ¿existen 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 #, al hacerlo, nos aseguramos de 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 biblioteca, y luego hacer un ensamblaje de prueba que use NUnit y enlaces a la biblioteca.

Answer 2

Funciona muy bien y le brinda la ventaja de tener pruebas parametrizadas, así como un corredor de pruebas y un marco comunes si está en un entorno mixto.

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

1. Si está siendo realmente exigente, las pruebas ya no se ejecutan en un entorno puramente nativo, por lo que existe la posibilidad externa de que algo funcione bajo prueba pero falle en el 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 de C ++ pueda ser incluido en un programa de C ++ / CLI. A veces, esto puede tener conflictos con los encabezados y obliga a su código a compilarse con UNICODE. En general, esto es algo bueno, ya que descubre bits de código engañosos (como el uso inconsistente de las variantes de Ansi de las llamadas de Win32). Tenga en cuenta que solo se incluyen los encabezados, por lo que es posible que muestre que está exponiendo los encabezados a un nivel demasiado alto; es probable que algunos de sus contenidos incluyan sus archivos de implementación de cpp.

Answer 3

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 el código nativo.

He intentado usar nunit para cargar un dll de prueba de c ++ / cli básico vinculado a " solo hilo " que es una implementación de la librería de hilos estándar de c ++. Los archivos de prueba ni siquiera se cargarán con la última versión de NUnit (2.6.2).

¡Definitivamente no es el camino a seguir!

Answer 4

Nunca usé uno, pero ¿no hay un puerto? Quizás http://cunit.sourceforge.net/documentation.html podría funcionar para usted.

Answer 5

La mayor preocupación es la curva de aprendizaje del lenguaje C ++ / CLI (anteriormente Managed C ++), si las pruebas deben ser comprendidas o mantenidas por desarrolladores que no sean de C ++.

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

Es posible que algunas personas nunca comprendan C ++ / CLI lo suficientemente bien 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 prueba de la unidad mientras mantiene el código de prueba ágil y capaz de responder a los cambios. Recomiendo el libro xUnit Test Patterns: Código de prueba de refactorización para ir en esta dirección .