¿Cómo puedo probar funciones y procedimientos ya que no pertenecen a clases en Delphi?

Question

Tengo varias pequeñas funciones en una unidad antigua llamada Utils.pas.

Ahora me gustaría refactorizar algunos de ellos, pero creo que es mejor escribir pruebas antes. Con Dunit creo que es imposible sin una clase.

Entonces, me gustaría saber cómo puedo probarlos antes de refactorizarlo.

Editar:

Pensé que era imposible porque estaba tratando de agregar un caso de prueba en Delphi usando el asistente de casos de prueba. Vea la imagen a continuación de que no hay clases y métodos, por lo que no puedo crearla.

Answer 1

No puede probar una función independiente usando el asistente, pero no es un problema probar una función independiente con Dunit.

Ejemplo

  //***** A Standalone function te be tested in a unit far, far away
  function Add(v1, v2: Integer): Integer;
  ...

  //***** A testclass to contain the testmethods calling our 
  //      standalone function     
  TTestAdd = class(TTestcase)
  published
    procedure AddingComplement_ShouldEqualZero;
    procedure AddingNegativeNumbers_ShouldBeLessThanZero
    ...
  end;

  implementation

  procedure TTestAdd.AddingComplement_ShouldEqualZero;
  begin
    // Setup, Execute & Verify
    CheckEquals(0, Utils.Add(-1, 1), 'Complement doesn''t add to zero');
  end;

  procedure TTestAdd.AddingNegativeNumbers_ShouldBeLessThanZero
  begin
    // Setup, Execute & Verify
    CheckEquals(-3, Utils.Add(-1, -2), 'Add doesn''t add');
  end;

Answer 2

AFAICT, DUNIT no requiere que el código bajo la prueba exista como métodos de clase. Solo los casos de prueba mismos deben ser clases.

EDITAR: El mago es solo una conveniencia. No tienes que usarlo.

Answer 3

El código real debe mantenerse. El código real tiene supuestos que no están bien documentados. El código real es cambiado por personas que olvidan o nunca conocieron esos supuestos. Confía en las pruebas, no confíes en el código.

Real TDD le permite crear el objeto y sus métodos antes de la implementación. Necesita un modelo claro antes de poder escribir un caso de prueba de todos modos.

Por lo tanto, genere los objetos, agregue los métodos, parámetros, etc. Probablemente usar UML2 sería mejor, luego escriba los casos de prueba para aquellos y luego implementa los objetos. Después de eso, ejecute el Profiler y descubra cuán horrible es realmente su código y refactorizado.

Como solución general, casi siempre es mejor escribir un objeto de fábrica para instanciar e inicializar sus objetos. Cuanto más se acerca a la funcionalidad central, más se vuelve importante.

Escriba pruebas para sus fallas y excepciones esperadas. Use un cheque para asegurarse.

Finalmente, escriba cada prueba y mire que falla antes de escribir el código para que tenga éxito.