Discussion :

[berceker united]

Bonjour.
Dans le monde objet il y a des outils permettant de tester les objets avec différent parametre. Ayant déjà vu cela en java et autre voila que cela existe aussi en php avec PhpUnit mais j'ai jamais compris le principe et comment cela s'utilise. Il y a des tuto mais c'est toujours la même chose ça n'explique pas grand chose sur le principe.
Quelqu'un pourrait-il m'expliquer ?
Merci

[Fladnag]

bon, dejà lit cet article

a partir de là, les tests unitaire en objet ont pour particularité de *pouvoir* etre codés dans l'objet lui meme (mais bon... c'est une question de point de vue)

par exemple :

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
class MaClass {
  function multiplie($a, $b) {
    return $a*$b;
  }
 
  function estDansTableau($element, $tableau) {
    return in_array($element, $tableau);
  }
  ...
  function test {
    echo "*** TEST UNITAIRE ***<br>";
    echo "multiplie : ".(($this->multiplie(3,5)===15)?'OK':'KO')."<br>";
    echo "multiplie : ".(($this->multiplie(0,5)===0)?'OK':'KO')."<br>";
    echo "multiplie : ".(($this->multiplie(-1,5)===-5)?'OK':'KO')."<br>";
    echo "multiplie : ".(($this->multiplie(-2,-4)===8)?'OK':'KO')."<br>";
    echo "estDansTableau : ".((!$this->estDansTableau(3,array(1,2,5)))?'OK':'KO')."<br>";
    echo "estDansTableau : ".(($this->estDansTableau(3,array(1,3,2,5)))?'OK':'KO')."<br>";
...
  }
}

Ensuite, lorsque tu modifie les methodes de ton objet, il suffit de lancer $objet->test() pour refaire tout les tests en une seule fois et verifier que toutes les methodes fonctionnent toujours.

Cela necessite de la volonté car il faut maintenir et adapter la methode de test en fonction de l'evolution du code des autres methodes.
De plus, cela te fait du "code mort" qui ne sera JAMAIS executé dans un environnement de production...

L'avantage est que si quelqu'un reprend ta classe pour l'ameliorer, il n'aura pas besoin de refaire tout les tests, tout sera deja pret.

Je dirais que c'est "un plus" qui peut etre appreciable sur les gros projets, mais ce n'est pas a mettre en application a chaque fois... vu le temps qu'on passe a maintenir un code qui, au final, si tout se passe bien, et s'il n'y a pas d'evolutions, ne sera executé qu'une seule fois.

[berceker united]

Ok, en faite c'etait ça le mystère, les tests il faut les monter soit même, il faut donner des conditions, parametre particuliers et tester si la classe arrive à tous gérer. Ceci en dehors de son environnement, je parle de l'objet d'ou le terme "Unitaire".

[BoneBreaker]

Oui c'est ça. Après tu as plusieurs façons de voir la chose. En gros tu a le "design by contract" soit donc la séquence classique :

1. Ecrire un test qui ne marche pas (exprès, on définit ce qu'on veut faire via les tests)
2. Ecrire la fonction/méthode qui va le faire marcher
3. Relancer le test et voir qu'il marche
4. Debugger/factoriser et vérifier que ça marche toujours

Si tu ne fais pas ça ou que tu as un gros projet 100% OO avec notamment des objets difficiles à répliquer en Mock, par exemple s'ils sont liés de très près à la base de données ben... oublie.

Sinon tu as la vision "opposée" : on ne teste que ce qui a un sens logique en programmetion (contrairement au DBC exposé ci-dessus où on n'hésite pas à faire des tests genre 1 + 1 == 2), mais une fois encore dès que le projet prend de l'ampleur ou quand tout est OO ça devient très lourd de s'y mettre, et comme dit Fladnag long à "entretenir".

[berceker united]

Ok, dans mon projet ou je suis entièrement POO et il y a des classes qui n'ont pas besoin de test. Il est vrai que si je fais tout tester je m'en sortirais pas quoi que mes classe sont quasiment des clones donc il suffit presque que j'en test une pour que les autres puisse être validé.
Soit il y a un mec qui est là que pour ça mais c'est lourd à maintenir.
Merci pour vos explication je vais m'y intéresser de plus pret avec moin de peur.