Comment puis-je tester les fonctions et les procédures comme ils ne le font pas appartiennent à des classes de Delphi?

Question

J'ai plusieurs petites fonctions dans une ancienne unité appelée Utils.pas.

Maintenant, je voudrais refactorisation certains d'entre eux, mais je pense qu'il est préférable de test d'écriture avant. Avec DUnit Je pense qu'il est impossible sans une classe.

Je voudrais savoir comment puis-je les tester avant de refactoring?

Modifier

Je pensais qu'il était impossible parce que je tentais d'ajouter un test dans Delphi en utilisant l'Assistant cas de test. Voir la photo ci-dessous qu'il n'y a pas de classes et méthodes, donc je ne suis pas capable de le créer.

Answer 1

Vous ne pouvez pas tester une fonction autonome à l'aide de l'assistant, mais ce n'est pas un problème pour tester une fonction autonome avec DUnit.

Exemple

  //***** 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 ne nécessite pas de code sous test pour exister en tant que méthodes de classe. Seuls les cas de test eux-mêmes doivent être des classes.

EDIT : L'assistant est juste une commodité. Vous ne devez pas l'utiliser.

Answer 3

Code réel doit être maintenu. Code réel a des hypothèses qui ne sont pas bien documentés. votre code est modifié par des gens qui oublient ou ne connaissaient ces hypothèses. Faites confiance aux tests, la confiance du code Do not.

réel TDD vous permet de créer l'objet et ses méthodes avant la mise en œuvre. Vous avez besoin d'un modèle clair avant de pouvoir écrire un test de toute façon.

générer l'objet (s), ajoutez les méthodes, les paramètres, etc. Probablement en utilisant UML2 serait mieux, alors écrire les cas de test pour ceux-ci, puis mettre en œuvre les objets. Après cette course le profileur et découvrez comment horribles votre code est vraiment et refactoring.

En tant que solution générale, il est presque toujours préférable d'écrire un objet usine pour instancier et initialiser vos objets. Plus vous obtenez à la fonctionnalité de base plus cela devient important.

Tests écriture pour vos échecs attendus et exceptions. utiliser un chèque pour vous assurer.

Enfin écrire chaque test et regarder échouer avant d'écrire le code pour le faire réussir.