Discussion :

[Dark Ryus]

Bonjour,

J'aimerais lors des tests unitaire de mon projet, pourvoir détecter dans mes controller si je suis en phase de test unitaire ou en phase site web.

Le but est de ne pas faire les commit en base de données lors des tests unitaire.

Merci d'avance

[Nathanael Marchand]

Ah mais oui mais non c'est pas comme ca qu'il faut fonctionner
Il faut que pour tes tests unitaires tu utilises une couche d'accès aux données spéciale qui rollbacke à chaque fin de test. Mais si tu modifies ton code pour y inclure ca, d'une ca testera pas convenablement et de deux c'est pas propre.

[StringBuilder]

Pour ma part, je préconiserais plutôt d'utiliser une base de données copie de la base de données de production, et faire les tests dessus, avec les commit.

En effet, un test unitaire peut être un peu plus complexe que "créer une ligne dans la table". Ça peut-être toute un ensemble de transactions qu'on désire tester, et à ce moment, il faut bien que l'ensemble des requêtes soient exécutées et enregistrées.

[Nathanael Marchand]

Ça peut-être toute un ensemble de transactions qu'on désire tester, et à ce moment, il faut bien que l'ensemble des requêtes soient exécutées et enregistrées.

C'est plus unitaire ca

[StringBuilder]

Ben oui et non.

Une fonction peut tout à fait déclencher tout un tas de traitements par derrière. Il faut bien pouvoir tester la fonction.

Par exemple, dans un cadre bancaire, je transfert mon compte chèque d'une agence à une autre :
-> Je dois faire les vérifications d'usage que j'ai bien le droit d'ouvrir un compte dans l'agence cible
-> Je dois faire les vérifications d'usage que j'ai bien le droit de fermer le compte dans l'agence source
-> Je dois créer un compte dans l'agence cible
-> Je dois débiter du compte cible des frais de dossier
-> Je dois débiter le compte source des frais de virement
-> Je dois débiter le compte source de son montant
-> Je dois créditer le compte cible du montant
-> Je dois faire la même chose avec les divers "comptes services" associés au compte chèque
-> Je dois faire les modifications sur tous les virements et prélèvements automatiques vers des comptes d'épargne qui sont liés au compte chèque
-> Etc.

Une bête fonction ChangerAgence(agence_source, agence_dest, num_compte) va faire une série de modifications dans la base, et seul le résultat total à un sens :
-> Le compte est bien clôturé dans la source
-> Le compte est bien ouvert et alimenté dans la cible
-> Je me suis bien gavé en frais de gestion de part et d'autres
-> L'ensemble des plans d'épargne rattachés au compte sont bien à jour pour les prochains prélèvements

Pour moi, même si c'est un macro-traitement, ça n'en reste pas moins un test unitaire.

Même si c'est une grosse unité

[StringBuilder]

Autre exemple plus concret :
-> Application de remises complexes sur une commande... Ben avant de pouvoir faire "le 3° produit de marque à moins 30%", il faut bien constituer la commande.
-> Après déduction des 30%, une autre offre qui est marqué "non cumulable" ne devra pas s'appliquer.
=> Il faut pouvoir tester qu'elle ne s'applique pas. Donc à nouveau, le test "unitaire" doit porter sur un jeu de données complet et une cascade de traitements.

[Nathanael Marchand]

Non! Ca n'est pas unitaire ca!
C'est des tests fonctionnels mais pas unitaires.
Unitaire comme le nom indique c'est qu'il teste juste une unité de code, pour cela on utilise des mocks pour toute la hiérachie en dessous. Si je teste la méthode CréerCommande() dans la couche business, il faut que tous les objets utilisés dans cette méthode soient mockés et notamment tous les appels à la couche d'accès aux données (ca peut etre une fausse couche qui renvoie un jeu de données écrit en dur dans le code).

[Dark Ryus]

Je vois que vous avez différents points de vue, mais cela ne me dit toujours pas si on peut détecter dans le controller si on est dans la phase de test ou d prod.

Je retient quand même dans un coin l'idée de dupliquer la base.

[Dark Ryus]

Ah mais oui mais non c'est pas comme ca qu'il faut fonctionner
Il faut que pour tes tests unitaires tu utilises une couche d'accès aux données spéciale qui rollbacke à chaque fin de test. Mais si tu modifies ton code pour y inclure ca, d'une ca testera pas convenablement et de deux c'est pas propre.

Le problème c'est que si je fait un commit dans mon controller, le rollback en mode "test" à la fin du test devient inutile...d'où l’intérêt de savoir si je suis en phase de test pour ne pas faire le commit.

[Nathanael Marchand]

L'idée est que justement tu n'en as pas besoin!
Si tu fais des tests sur le business, ou doivent se trouver les transactions, ta couche d'accès n'étant pas la couche d'accès à la base mais une version "mockée" par tes soins, le commit fait ce que tu décides.
Si tu fais des tests sur la couche d'accès, alors tu n'as pas à tester les transactions et par conséquent tu peux rollbacker.

[Dark Ryus]

heu j'ai pas tout compris là lol.

Je donne un exemple d'une fonction index dans un controller, voila ce que je fait :

Code VB :

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
Function Index() As ViewResult
            ViewBag.Test = "essai"
 
            Dim objProvider As ProviderOracle = New ProviderOracle
            ' transaction
            Dim transaction As OracleTransaction
 
            Try
                ' Début de la transaction locale
                transaction = objProvider.connexion.BeginTransaction(IsolationLevel.ReadCommitted)
                objProvider.transaction = transaction
 
                unUpdate()
 
                transaction.Commit()
            Catch ex As Exception
                transaction.Rollback()
            End Try
 
            Return View()
        End Function

Et je veux pas faire mon commit en mode 'test'

J'espère que je me fait comprendre ^^

[Nathanael Marchand]

La, le problème est que ton code n'est pas testable.
Il n'y a pas de découpage en couche et d'indépendance entre les couches.
On ne met pas directement les accès à la base de donnée dans le code du controleur. Il faut en plus abstraire la connection Oracle pour pouvoir la mockée comme expliqué plus haut.
Bref, avant d'attaquer les tests unitaires, il faut réarchitecturer correctement ton code
http://philippe.developpez.com/artic...roductionMock/
http://bruno-orsier.developpez.com/mocks-arent-stubs/
http://nathanaelmarchand.developpez....ces-avec-unity

[Dark Ryus]

Merci pour toutes ces infos, mais là ça complique un peu beaucoup ma tâche ^^ et je n'ai pas le temps de mettre tout ça en place.

Je vais faire une duplication de ma base et l'utiliser spécialement pour les tests, ça sera plus simple pour moi.

Merci pour les infos