Desarrollamos una aplicación C++ usando Visual Studio 2008 y una prueba de unidad usando Boost.Test. Por el momento, tenemos una solución separada que contiene nuestras pruebas unitarias.Unidad probando clases no exportadas en una DLL
Muchos de nuestros proyectos en la solución principal producen DLL. Estamos limitados en la cobertura de prueba porque no podemos evaluar clases no exportadas.
Tengo dos ideas sobre cómo podrían ser probados:
- exportación de muebles
- ponen las pruebas dentro de la DLL (mismo proyecto y la solución) y el uso corredor externo de Boost.Test
No estoy del todo seguro de cuáles serían los inconvenientes. El número 1 anterior rompe la encapsulación a nivel de módulo, y el número 2 podría dar como resultado una DLL mucho más grande, a menos que solo sea posible incluir el código de prueba en ciertas configuraciones.
Entonces, ¿hay algún inconveniente grave en los métodos anteriores, o puede pensar en otras soluciones?
Me gustaría dar una pista sobre [CMake] (http://www.cmake.org) ofreciendo una característica llamada "bibliotecas de objetos". ('add_library (foo_obj OBJECT ...)') En mis proyectos, construyo las fuentes en bibliotecas de objetos, que luego enlace a * ambas * la DLL ('add_library (foo SHARED ... $)') * y * sus controladores de prueba ('add_executable (foo_test ... $ )'). Es una variante de las respuestas a continuación usando un sistema de compilación diferente (por lo que agregué esto como un comentario, no como una respuesta), pero está resolviendo el mismo problema. –
DevSolar