Maledetto JUnit :)
chopinx04
Hash: SHA512
Riciao a tutti,
vedo che qualcuno oggi mi risponde :) per cui approfitto e posto un
altro problema che mi sta affliggendo da qualche giorno a questa parte.
Per un esame all'universit� di Bolzano sto scrivendo un progetto in
Java e diciamo che sto complicandomi un p� la vita, ma almeno sto
imparando qualcosa per cui tiro avanti. Nel scrivere qualche test
junit per le poche classi che ho finito mi sono imbarcato in qualcosa
che forse era meglio avessi evitato: visto che le classi fanno
connessioni ad un server LDAP e per non hard-encodare i parametri di
connessione ho avuto la geniale idea di "esportare" i parametri in
file xml (anche perch� ho un altro esame sull'xml e smaneggiare mi ha
dato una mano a capirci qualcosa di pi�).
Googla che ti rigoogla ho scoperto "Parameterized.class" che permette
di parametrizzare i test, e ho anche scoperto junit-ext che � un
estensione che d� la possibilit� di rendere i test condizionali ed
evitare di eseguire alcuni test piuttosto che altri....... ed ecco il
problema: da quello che ho capito le due classi non le posso usare
assieme in una classe unica di test perch� vanno inserite in
@RunWith() che prendere come parametro una classe sola (doh!).
Per cui ora mi ritrovo un parser xml che restituisce il necessario a
@Parameters ma non ho un modo per far eseguire i test in modo
condizionale.. L'alternativa che m� passata per la testa �
parametrizzare i test nel senso che se si verifica la condizione per
cui il test andrebbe non eseguito allora potre inserire qualcosa del tipo:
[..]
if ( !hasToBeExecuted() )
assertTrue( false );
[..]
cos� che lo esegue lo stesso ma � come se non lo facesse...
spero che qualcuno mi possa aiutare con un idea un p� pi� intelligente..
thnx,
A.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEAREKAAYFAks8jzEACgkQ4bGOEGfZtvMpdQCfYUlFKfDBsGrjgDvyQ3GM8PH5
AHwAn3hShd0U8A7czOgiRCA78RHlSEHC
=tLlw
-----END PGP SIGNATURE-----
chopinx04
> [..]
> if ( !hasToBeExecuted() )
> assertTrue( false );
> [..]
nel mentre avevo dimenticato un'altra idea che mi era balenata per la
testa, un pò meno furba però: usare nested classes e "specializzare"
ogni nasted class a fare una o un gruppo di cose.. ma in questo caso
dovrei riparsare l'XML per ogni "sotto" classe .. il che mi sembra uno
spreco di risorse (anche se, effettivamente, coi processori di oggi
questo problema non si dovrebbe porro ..
thnx,
A.
chopinx04
alla fine ho implementato l'opzione "meno sbattimento": in sostanza
inserisco un "assertTrue(true)" condizionato o un "throw new Exception
("qualcosa")" sempre condizionato e ho aggiunto un System.out.print
( "I" ) giusto da identificare che il test in realtà è stato skippato.
Armando
Juri
dovrebbe fare connessioni a server remoti etc. Un unit test fa un test
di una "unit" e solo di quella. Praticamente nel caso di una classe
tua che fa connessioni a un server LDAP dovresti testare solo la
logica di un tuo metodo (p.e.) verifyAccountOverLDAP(Account). Usando
librerie mock (http://stackoverflow.com/questions/22697/whats-the-best-
mock-framework-for-java) verifichi la logica di mandare diciamo le
credenziali e l'elaborazione corretta di un risultato positivo/
negativo.
Testare la logica di una connessione al server LDAP sarebbe in teoria
fuori dallo scopo di un unit test. Io personalmente lo definisco
questi test sempre come tipo di "integration test". Li metto in un
package (o anche progetto) separato. Perché questo:
- un unit test dovrebbe essere veloce nella sua elaborazione (che
potrebbe non essere il caso di una connessione remota)
- un unit test non dovrebbe mai fallire (non essendo in mezzo di un
cycle TDD ;) )
Dall'altra parte un (chiamiamolo) "integration test"
- potrebbbe fallire (p.e. server remoto non risponde, non c'è una
connessione ad internet..)
Qui alcune referenze:
http://stackoverflow.com/questions/1257560/when-is-a-test-not-a-unit-test
http://stackoverflow.com/questions/1382313/how-do-i-specify-test-method-parameters-with-testdriven-net
Juri