Pregunta

Teniendo en cuenta dicho código:

class ToBeTested {
public:
  void doForEach() {
    for (vector<Contained>::iterator it = m_contained.begin(); it != m_contained.end(); it++) {
       doOnce(*it);
       doTwice(*it);
       doTwice(*it);
    }
  }
  void doOnce(Contained & c) {
    // do something
  }
  void doTwice(Contained & c) {
    // do something
  }

  // other methods
private:
  vector<Contained> m_contained;
}

Quiero probar que si completo el vector con 3 valores, mis funciones se llamarán en el orden y la cantidad adecuados.Por ejemplo, mi prueba puede verse así:

tobeTested.AddContained(one);
tobeTested.AddContained(two);
tobeTested.AddContained(three);

BEGIN_PROC_TEST()
SHOULD_BE_CALLED(doOnce, 1)
SHOULD_BE_CALLED(doTwice, 2)
SHOULD_BE_CALLED(doOnce, 1)
SHOULD_BE_CALLED(doTwice, 2)
SHOULD_BE_CALLED(doOnce, 1)
SHOULD_BE_CALLED(doTwice, 2)

tobeTested.doForEach()
END_PROC_TEST()

¿Cómo recomiendas probar esto?¿Existe algún medio para hacer esto con los marcos CppUnit o GoogleTest?¿Quizás algún otro marco de prueba unitaria permita realizar tales pruebas?

Entiendo que probablemente esto sea imposible sin llamar a ninguna función de depuración desde estas funciones, pero al menos se puede hacer automáticamente en algún marco de prueba.No me gusta escanear registros de seguimiento y comprobar su corrección.

UPD:Estoy tratando de comprobar no sólo el estado de un objeto, sino también el orden de ejecución para evitar problemas de rendimiento en la etapa más temprana posible (y en general quiero saber que mi código se ejecuta exactamente como esperaba).

¿Fue útil?

Solución

Si está interesado en el rendimiento, le recomiendo que escriba una prueba que mida el rendimiento.

Verifique la hora actual, ejecute el método que le preocupa y luego verifique la hora nuevamente.Afirme que el tiempo total necesario es menor que cierto valor.

El problema al verificar que los métodos se llamen en un orden determinado es que su código tendrá que cambiar y no querrá tener que actualizar sus pruebas cuando eso suceda.Deberías concentrarte en probar el requisito real en lugar de probar el detalle de implementación que cumple con ese requisito.

Dicho esto, si realmente deseas probar que tus métodos se llaman en un orden determinado, deberás hacer lo siguiente:

  1. Muévelos a otra clase, llámala Colaborador.
  2. Agregue una instancia de esta otra clase a la clase ToBeTested
  3. Utilice un marco simulado para configurar la variable de instancia en ToBeTested para que sea una simulación de la clase Collborator
  4. Llame al método bajo prueba
  5. Utilice su marco de burla para afirmar que los métodos fueron llamados en su simulacro en el orden correcto.

No soy un hablante nativo de cpp, por lo que no puedo comentar sobre qué marco de referencia debería usar, pero veo que otros comentaristas han agregado sus sugerencias en este frente.

Otros consejos

Podrías comprobar maqueta.

Debería poder utilizar cualquier buen marco de simulación para verificar que las llamadas a un objeto colaborador se realicen en un orden específico.

Sin embargo, generalmente no se prueba que un método realice algunas llamadas a otros métodos en la misma clase...¿por que lo harias?

Generalmente, cuando pruebas una clase, solo te importa probar su estado visible públicamente.Si prueba algo más, sus pruebas le impedirán refactorizar más tarde.

Podría brindar más ayuda, pero no creo que su ejemplo sea consistente (¿Dónde está la implementación del método AddContained?).

En lugar de intentar averiguar cuántas funciones se llamaron y en qué orden, encuentre un conjunto de entradas que solo puedan producir el resultado esperado si llama las cosas en el orden correcto.

Algunos marcos simulados le permiten configurar expectativas ordenadas, lo que le permite decir exactamente qué llamadas de función espera en un orden determinado.Por ejemplo, Rinocerontes para C# permite esto.

No soy un codificador de C++, por lo que no sé qué hay disponible para C++, pero ese es un tipo de herramienta que podría permitir lo que estás intentando hacer.

http://msdn.microsoft.com/en-au/magazine/cc301356.aspx

Este es un buen artículo sobre objetos vinculados al contexto.Contiene algunas cosas muy avanzadas, pero si no eres vago y realmente quieres entender este tipo de cosas, será de gran ayuda.

Al final podrás escribir algo como:CallTracingAttribute ()] Public Class Traceme:Contextboundobject {...}

Puede utilizar marcos de depuración ACE (o similares) y, en su prueba, configurar el objeto de depuración para transmitirlo a un archivo.Entonces solo necesitas verificar el archivo.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top