2010-11-30 9 views
8

estoy mirando algunas librerias de pruebas unitarias en C++ y tengo algunas preguntas:C++ pruebas unitarias, objetos de burla

  1. no parece haber ninguna instalación de burla en boost.test pero difícilmente pueden pensar haciendo pruebas unitarias sin crear objetos/funciones falsas. ¿Cómo harías eso en boost.test? ¿Lo estás haciendo manualmente? (¿Cómo? Quiero decir, hay varias maneras en que puedo pensar, ninguna de estas parece agradable) o simplemente lo haces sin simular objetos.

  2. googletest y googlemock se ven como lindas librerías con mockingsupport, sin embargo, requiere que todos los objetos que se burlan sean virtuales. Realmente no me gusta esto, no es que me preocupe por el rendimiento (podría definir una macro para sacarlo del código de producción de todos modos), pero me parece muy intrusivo. Me pregunto si hay otra solución que no requiera tantos cambios en el código existente. (Clojure amor existe)

+3

Escribe tus burlas a mano. Descubrirá lo que puede y no puede hacer en el idioma. –

Respuesta

6
  1. Boost :: prueba no tiene un marco de burla o biblioteca. Si quieres burlarse, tienes que hacerlo tú mismo, o usar algo como GMock. Por supuesto, puedes usar google mock con Boost :: Test sin problemas.
  2. ¿De qué otro modo esperaría que algo se burlara? ¡Así es como funciona en cualquier otro lenguaje de programación! (Bueno, no con la tipificación de pato, pero que lleva más sobrecarga de métodos virtuales) Si usted está preocupado por el rendimiento:

    1. Implementar todo en términos de los virtuales como se especifica en los documentos de Google en general simuladas.
    2. Perfile su código para lugares donde no es suficiente
    3. Reemplace las secciones perfiladas (o mejor dicho, el segmento de su código que indica el rendimiento es un problema) con high-perf dependency injection en su lugar.
    4. No reemplace todo con DI de alto rendimiento, ya que eso enviaría tiempos de compilación a través del techo.

    Sin embargo, con toda seriedad, no creo que las llamadas virtuales tengan grandes diferencias en el rendimiento. El único caso en que los virtuales son malos es donde están ubicados dentro de los bucles internos (como en la biblioteca iostream donde se llaman posiblemente para cada carácter de entrada o salida), e incluso solo en el código sensible al rendimiento.

EDIT: que se perdió la palabra muy importante no en la pregunta anterior # 2 - que eres no preocupado por el rendimiento. Si ese es el caso, entonces mi respuesta es que efectivamente estás jodido. Una función simple o una llamada a un método en C++ genera una llamada de método simple, y no hay oportunidad para que usted cambie dónde señala esa llamada. En la mayoría de los casos esto no requiere demasiado mucho cambio de código, porque el código correcto de C++ utiliza referencias siempre que sea posible, que no será necesario modificar a pesar del hecho de que se usan los virtuales. Sin embargo, deberá tener cuidado con cualquiera que use semántica de valores, ya que estarán sujetos al problema de corte.

+0

>> ¿De qué otra manera esperarías que algo se burlara? ¡Así es como funciona en cualquier otro lenguaje de programación! en clojure, por ejemplo, podría vincular de forma dinámica y temporal una función a otra función utilizando el formulario de enlace (vinculante [foo mock-foo] ...) – DaVinci

+0

@DaVinci: Puede hacer lo mismo en C/C++ usando una macro o una costura de enlace, aunque eso es mucho más incómodo, por supuesto. –

+0

Pude entender si el OP tenía limitaciones de rendimiento de que algo podría no ser posible dentro de esas limitaciones, pero no entiendo cómo * no * preocuparse por el rendimiento podría significar que el OP está "efectivamente atornillado". –

6

Turtle fue diseñado explícitamente para usar con Boost.Test y se ve muy bien para mí.

4

Descargo de responsabilidad Trabajo en Typemock.

Typemock Isolator++ pueden burlarse de nada !! No es necesario virtuales - todo es mockable

Ver explanation here

Por lo que puede pública falsa, privado, abstracta (sin llegar a la creación de una clase concreta), los argumentos, ejemplo vivo no virtuales, etc ... Y ... Se falsifica todo lo recursiva

class MyClass 
{ 
    int GetResult() { return -1; } 
} 

usaremos el siguiente código

MyClass* fakeMyClass = FAKE<MyClass>(); // every call to fakeMyClass will be faked 
WHEN_CALLED(fakeMyClass->GetResult()).Return(10); 
Cuestiones relacionadas