Discussion :

[nuriel2]

Salut,

Quelques questions sur JUnit et les tests en general :

1- Dans certains tests, j'espere qu'une methode lancera une exception. Je gere cela en capturant Exception et en utilisant instanceof pour voir si j'ai bien recupere l'exception attendue. Cependant, si la methode ne leve pas d'exception, pas de test, et donc sauf a lire les logs en detail, je n'arriverai pas a dire si le test a reussi parce que l'exception a ete lancee ou parce qu'aucune n' a ete generee. Y a t il un moyen avec JUnit d'echouer le test si l'exception n'est pas generee ? Un test en exemple : mettre a jour un record dans une base contenant des chambres d'hotel. Le 3eme test correspond a la question ci-dessus :

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
/**
         * Test method for {@link suncertify.db.RoomFileAccess#update(int, java.lang.String[], long)}.
         * @throws RecordNotFoundException 
         * @throws DatabaseFailureException 
         * @throws SecurityException 
         */
	@Test
	public final void testUpdate() throws SecurityException, DatabaseFailureException, RecordNotFoundException {
		String[] oldRecord = {"Palace", "Smallville", "2", "Y", "$150.00", "2005/07/27", ""};
		String[] newRecord = {"Sofitel", "Paris", "5", "N", "$1110.00", "2010/03/14", ""};
		String[] recordWithCookie = {"Belgravia", "Tokyo", "2", "3", "$110.00", "2020/12/20", "2345"};
		String[] invalidRecord = {"Novotel", "London", "1", "N", "$1111110.00", "2010/03/14", ""};
 
		/*
		 * Updating first record
		 */
		rfa.update(0, newRecord, 15);
		assertTrue(Arrays.equals(rfa.read(0), newRecord));
 
		/*
		 * Updating 24th record
		 */
		rfa.update(23, oldRecord, 15);
		assertTrue(Arrays.equals(rfa.read(23), oldRecord));
 
		/*
		 * Updating a deleted record
		 * Should raise a RecordNotFoundException
		 */
		rfa.delete(27, 15);
		try {
			rfa.update(27, newRecord, 15);
		} catch (Exception e) {
			assertTrue(e instanceof RecordNotFoundException);
		}
 
		/*
		 * Updating a record with a different cookie
		 * Should raise a SecurityException
		 */
		try {
			rfa.update(20, recordWithCookie, 15);
			rfa.update(20, newRecord, 15);
		} catch (Exception e) {
			assertTrue(e instanceof SecurityException);
		}
 
		/*
		 * Updating a record with the same cookie
		 */
		rfa.update(20, oldRecord, 2345);
 
		/*
		 * Updating a record with an invalid entry - too big to go in
		 * Should raise a DatabaseFailureException
		 */
		try {
			rfa.update(13, invalidRecord, 15);
		} catch (Exception e) {
			assertTrue(e instanceof DatabaseFailureException);
		}
 
	}

2- Chacune des methodes testee laisse la BDD (un fichier texte) dans un etat instable. Dans l'exemple ci-dessus, je delete des records, en ajoute, etc... mais derriere pour tester une autre methode, j'ai besoin de reinitialiser la BDD a son etat d'origine. Pour l'instant, j'ai un script qui permet de detruire l'ancienne version et de copier un backup a la place, ce qui me force a lancer les tests manuellement, un a un, en reintialisant la BDD apres chaque test.
Y a t il un moyen simple pour resoudre ce probleme ? J'imagine que je ne suis pas le 1er a tomber dessus, mais mes recherches n'ont rien donne pour automatiser tout cela. setUp() ne semble pas etre la voie.

3- Dans le registre methodologies de test recommandees, chacune de mes methodes de test depend (fortement ?) des autres. Dans le test ci-dessus par exemple, j'appelle delete(), et chacun des appels d'update() implicitement fait appel a read(). J'ai donc l'impression de creer beaucoup d'interdependances. J'ai verifie que read() et delete() sont solides avant de construire les autres methodes ainsi que leurs tests, mais je me demande si cela (ie, creer des interdependances) est une bonne pratique et si vous ecriviez ainsi vos tests.

Merci.

Nuriel

[tchize_]

1. oui, en général (c'est controversé mais bon), le test ressemble à ça

Code :

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

1
2
3
4
5
6
7
8
 
boolean gotit = false;
try {
 monObject.methodeAtester();
} catch (ExceptionAChoper e){
   gotit=true:
}
assertTrue(gotit,"on aurait du avoir ExceptionAChoper");

2. C'est le rôle des méthode setup et tearDown de préparer au test / nettoyer après le test. Ces méthodes sont appelé entre chaque méthode test

3. Tu dois éviter de te répéter inutilement dans tes tests. Si tu as déjà une méthode qui teste la cohérence de update(), alors tu peux présupposer dans ton test (éventuellement document) que les update fonctionne et tester uniquement delete. Si tu documente bien, le jour ou t'aura des exceptions de derrière les fagots dans ton testDelete, tu ira voir la doc du test qui dira 'nécessite le fonctionnement correct de update' et tu verra que testUpdate a fail -> pas besoin de cherche pourquoi delete a foiré

[CyberChouan]

Pour tester une exception, j'utilise plutôt cette syntaxe, plus concise car ne nécessitant pas de booléen (mais comme dit tchize_, c'est controversé et chacun a ses manies dans le codage des tests ) :

Code :

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

1
2
3
4
5
6
try {
    methodeTestDevantLeverUneException();
    fail("Il aurait dû y avoir une exception");
} catch(Exception e) {
    // Test passé avec succès !
}

[nuriel2]

Merci.

Concernant l'exception, je vais prendre l'option boolean, qui dans mon cas me donne un plus grand control.

Resolu mon probleme avec la methode setUp() mais je n'ai aucune idee de comment.

Quant a la documentation, plus j'avance dans ce projet, et plus je me rends compte qu'elle est importante.

Nuriel