Coding rules Tests - TecostNetwork/Network GitHub Wiki

Constantes pour les ids

Il ne faut jamais mettre d'id en dur mais utiliser des constantes. Et il faut toujours passer les indexes en paramètre (jamais en dur, jamais dans la constante).

Il ne faut pas faire : 

click("myForm:myIteration:3:btnEdit");

public final static String BTN_EDIT = "myForm:myIteration:3:btnEdit";
click(BTN_EDIT);

Mails il faut faire : 

public final static String BTN_EDIT = "myForm:myIteration:$:btnEdit";
click(BTN_EDIT, 3);

AssertEquals

Au lieu de mettre : 
assert myItems.size() == 2 : "TWO items should appear";

Il faut utiliser plutôt : 
assertEquals(2, myItems.size());

Les avantages sont : 

• Pas besoin d'écrire le texte de l'assertion, ce qui rend le test plus rapide à écrire et moins encombré au niveau du code.
• Pas besoin de maintenir le texte si on change la valeur (ça arrive d'avoir un texte pas à jour).
• Lorsque le test plante, au lieu d'écrire "TWO exportation should appear", ça écrira un truc du genre "Expected : 2, actual : 3" ce qui permet de voir sans relancer le test quelle est la mauvaise valeur. Quand on a 10 assertions qui vont planter suite à un changement, ça permet de lancer le test 10x au lieu de 20x (une fois pour voir où ça plante, et une fois avec un breakpoint pour voir la valeur).

Attention juste pour le asserEquals(expected, actual) la valeur attendue est le 1er paramètre et la valeur réelle est le 2ème paramètre.
Il y a aussi la possibilité de mettre un commentaire via assertEquals(message, expected, actual) s'il faut préciser la raison pour laquelle l'assertion plante ou le contexte, mais en général quand on a la valeur et qu'on regarde le test, ça suffit souvent pour comprendre ce qui ne va pas.

Éviter les schrodingers

pour éviter ou résoudre les schrodinger : évitez d'utiliser des finders en milieu de test et de prendre le 1er élément car techniquement chaque appel au finder ne retourne pas toujours les éléments dans le même ordre.

Par exemple :

HealthServiceRequest request = ApplicantHealthRequestUtils.insertDummyRequest(applicant, HealthServiceType.findAll(HealthServiceType.class, DbType.MAIN).get(0));
HealthServiceRequest request1 = ApplicantHealthRequestUtils.insertDummyRequest(applicant, HealthServiceType.findAll(HealthServiceType.class, DbType.MAIN).get(1));

Lorsqu'on a ces deux appels successifs, ça peut tout à fait retourner 2x le même élément car le finder va retourner les éléments dans un ordre aléatoire :

HealthServiceType.findAll(HealthServiceType.class, DbType.MAIN).get(0);
HealthServiceType.findAll(HealthServiceType.class, DbType.MAIN).get(1);

Et plus tard si on fait ça, il y a des chances que cela ne retourne pas l'élément auquel on s'attend :

assert serviceType.equals(HealthServiceType.findAll(HealthServiceType.class, DbType.MAIN).get(0))

La bonne solution ici est de créer une liste en début de test en appelant qu'une seule fois le finder : 

//Je cherche mes éléments
List<HealthServiceType> hsType = HealthServiceType.findAll(HealthServiceType.class, DbType.MAIN); 

//J'insère des données en utilisant ma liste
HealthServiceRequest request = ApplicantHealthRequestUtils.insertDummyRequest(applicant, hsType.get(0));
HealthServiceRequest request1 = ApplicantHealthRequestUtils.insertDummyRequest(applicant, hsType.get(1));

//Via l'ihm pareil, j'utilise ma liste
getSelectOneMenu("xxx").setSelectedEntity(hsType.get(0));

//J'asserte toujours en utilisant ma liste
assert myExpectedItem.equals(hsType.get(0));
assert getDataTable("xxx").contains(hsType.get(0).getName());

On peut également stocker dans des variables simples au lieu d'une liste si on n'a qu'un élément ou si on veut faire plusieurs variables.