Come posso testare le funzioni e le procedure in quanto non appartengono alle classi a Delphi?

Question

Ho diverse piccole funzioni in una vecchia unità chiamata Utils.pas.

Ora vorrei refactoring alcuni di loro, ma penso che sia meglio scrivere test prima. Con Dunit penso che sia impossibile senza una classe.

Quindi mi piacerebbe sapere come posso testarli prima del refactoring?

Modificare:

Ho pensato che fosse impossibile perché stavo cercando di aggiungere un caso di prova in Delphi usando la procedura guidata del caso di prova. Guarda l'immagine sotto che non ci sono classi e metodi, quindi non sono in grado di crearla.

Answer 1

Non è possibile testare una funzione autonoma usando la procedura guidata ma non è un problema testare una funzione autonoma con Dunit.

Esempio

  //***** 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 non richiede che il codice in test esista come metodi di classe. Solo i casi di test stessi devono essere classi.

MODIFICARE: Il mago è solo una comodità. Non devi usarlo.

Answer 3

Il codice reale deve essere mantenuto. Il codice reale ha ipotesi che non sono ben documentate. Il codice reale è cambiato da persone che dimenticano o non hanno mai conosciuto tali ipotesi. Fidati dei test, non fidarti del codice.

Il TDD reale consente di creare l'oggetto e i suoi metodi prima dell'implementazione. Hai bisogno di un modello chiaro prima di poter scrivere comunque una custodia di prova.

Quindi genera gli oggetti, aggiungi i metodi, i parametri ecc. Probabilmente l'uso di UML2 sarebbe meglio, quindi scrivere i casi di test per quelli e quindi implementare gli oggetti. Dopodiché gestisce il profiler e scopri quanto sia orribile il tuo codice e refactor.

Come soluzione generale è quasi sempre meglio scrivere un oggetto di fabbrica per istanziare e inizializzare i tuoi oggetti. Più si avvicina alla funzionalità di base, più diventa importante.

Scrivi test per i tuoi fallimenti ed eccezioni previste. Usa un assegno per assicurarti.

Infine, scrivi ogni test e guardalo fallire prima di scrivere il codice per farlo avere successo.