Discussion :

[rad_hass]

Bonjour à tous,

Je ne vais pas ressortir le débat sur les tests unitaires avec la base de données qui a déjà été traité mutlfois

Mais plutôt savoir en pratiquant le TDD comment tester vous un Update par exemple ?
Effectivement il est possible d'avoir un scénario Insert, Select, Update, Select mais ce n'est plus vraiment un test unitaire complètement indépendant non ?

D'avance merci pour vos retours ;-)

PS : Si vous connaissez un bouquin sur le TDD (.net de préférence) en Fr ça serait génial ;-)

[Maximil ian]

Salut,

Je n'ai pas très bien compris, tu essaies de faire un test unitaire pour tester le comportement d'une méthode d'une classe (exemple : la méthode Update de ton contrôleur/présenteur), ou un test de plus haut niveau qui implique plusieurs couches de l'application, et donc se rapprocherait plus d'un test d'intégration ?

Si j'avais un livre à te conseiller (mais qui n'est ni en français ni très axé TDD ) : The Art of Unit Testing de Roy Osherove.

[rad_hass]

Salut Maximilian

tu essaies de faire un test unitaire pour tester le comportement d'une méthode d'une classe (exemple : la méthode Update de ton contrôleur/présenteur)

Oui c'est exactement ça ;-) (Enfin plutôt au niveau DAO ;-) ).

Pour l'instant ce que je fais comme Test, c'est un Select de mon objet (BeforeUpdate), un Update et à nouveau un Select (AfterUpdate)
Et je compare BeforeUpdate et AfterUpdate. Le problème c'est que le Test de la méthode Update implique la méthode Select

Merci pour le livre, il a effectivement l'air excellent

[Maximil ian]

Si c'est un DAO, c'est particulier. On ne peut pas vraiment tester la DAL sans vérifier que l'écriture dans la base de données se fait bien. En d'autres termes on ne peut pas isoler complètement le code testé de tout élément extérieur (le SGBD, en l'occurrence).

Est-ce toujours des tests unitaires ? Je ne pense pas vraiment, car tu as besoin de la présence d'un élément en base pour que ton test du DAO fonctionne.

Du coup je ne vois pas d'autre solution qu'exécuter le scénario dont tu parles, mais ce n'est pas forcément grave vu que de toute façon notre test n'est sans doute déjà pas atomique... L'important étant qu'il existe un autre test pour les fonctionnalités annexes dont tu es obligé de te servir dans ce test

[hegros]

Te donner un exemple complet n'est pas possible puisque d'un test à l'autre la conception et l'implémentation change d'une équipe/personne à une autre, en tout cas je te propose ce bout de code de test en delphi il ne passe pas encore le test de la compilation (voyant rouge) pour passer au voyant vert il va falloir corriger ces erreurs en implémentant tout cela, ce qui est bien est qu'il est possible de faire émerger un code automatiquement et les modèles UML

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Unit TestCreateDataWithSGBD;

type

TTestCreateDataWithSGBD = class(TTestCase)

published

procedure TesterCreateOneData;


end;


TTestCreateDataWithSGBD.TesterCreateOneData;
var
testOneData :TTestCreateOneData;
begin
//pré-condition
testOneData := TTestCreateOneData.Create;

//event
FacadeSgbd.CreateOneData(testOneData);

//post condition
CheckTrue(FacadeSgbd.IsCreatedInBuffer(testOneData),'IsCreatedInBufferfailed');
CheckTrue(FacadeSgbd.IsCreatedOnSupport(testOneData),'IsCreatedOnSupportfailed');
end;