Discussion :

[Invité]

Bonjour,

Je travaille depuis quelques semaines sur une application WPF. Pour poser le décor, voici un bref aperçu de l'architecture de la solution :

UI :
Shell
Modules

La partie UI est composée d'un Shell (une sorte de lanceur) qui s'occupe de charger les différents modules lorsque l'utilisateur clique sur le menu approprié (utilisation de MEF).
A noter que la partie UI fonctionne sur le principe MVVM (avec MVVM Light de Galasoft).

Services WCF :
Le service WCF contient la couche d'accés aux données (Entity Framework), les process, ...

Jusqu'à maintenant, je n'ai pas encore eu le temps de mettre en place le moindre tests. J'aimerais corriger cela et le faire de la meilleure manière qui soit.

Le problème, c'est que je ne sais pas trop quelles parties de l'application tester ou non.

Faut t'il mettre les tests côté UI (en appelant le service WCF dans le test) ? Côté Service ? Des deux côtés ?

Prenons un exemple simple, la création d'un Client.

Côté UI, j'ai une méthode sur mon ViewModel qui s'execute sur la command du click du bouton "Enregister".
Cette méthode appelle elle même une méthode placée sur mon Model.
La méthode du Model appelle la méthode appropriée (AddCustomer) sur le service WCF.

Sur le Service WCF, la méthode AddCustomer se charge d'ajouter le client via EF.

Faut t'il placer des tests sur chacune de ces méthodes ?

Un test placé côté UI sur la méthode qui crée un client doit il remonter jusqu'à la création complète du client côté service ?

Dans ce cas, si je fais un test côté UI et que l'ajout du client s'effectue bien, je ne vois pas trop l'intérêt de faire un nouveau test côté service rien que pour la méthode AddCustomer.

Merci d'avance pour votre aide.

[Nathanael Marchand]

Comme l'indique son nom, un test unitaire doit être unitaire.
Chaque couche doit avoir sont projet de test. Lorsque tu testes un objet, il ne doit surtout pas appeller tout une autre chaîne d'objet: il faut mocker!
Si tu dois tester ton viewModel, il faut mocker les appels au service. Si tu dois tester ta couche métier, tu dois mocker la couche d'accès aux données. Sinon tu te retrouves à tester la terre entière sans que ca soit unitaire

[Invité]

C'est bien ce que je supposais.

Par contre, qu'entends tu par "Mocker les appels au service" exactement ?

[Nathanael Marchand]

En utilisant un framework comme RhinoMock ou Moq, tu peux faire une implémentation de la même interface que ton service. Ce mock est en fait un service de test très utile pour les tests unitaires (on sait par exemple ce qu'il doit renvoyer etc.)
http://en.wikipedia.org/wiki/Mock_object

[hegros]

A mon avis, maintenant que tu as terminé de coder alors écrire des tests unitaires n'a que très peu d’intérêts puisqu'il faut les écrire avant.

Tu devrais commencer d'abord par écrire des tests d'acceptance qui tests toute la chaîne en partant de la couche UI, si tu utilises la dernière version de Ms Test alors tu pourrais enregistrer des scénarios que tu veux comme ajouter des clients etc...

Ensuite tu peux toujours écrire des tests unitaires à posteriori cependant cela va être plus compliqué sur du legacy code puisque ta conception est terminée mais bon cela pourrait mettre en évidence certains problèmes et permettre de démarrer en commençeant par les tests pour les autres classes ou méthodes