Lavoro su un'applicazione Java di piccole / medie dimensioni. Nel corso del tempo, ho cercato di assicurarmi che i test che scrivo fossero "buoni" e che ce ne fossero molti. Quindi ho esaminato varie metodologie di test più rigorose, come l'analisi del valore al contorno, test combinatori e altri metodi di test.
Tuttavia, molti di questi hanno esempi molto secchi e gli esempi non si adattano molto bene al mio dominio, poiché gli esempi sono per lo più funzioni di dati numerici. Le mie funzioni non sono quasi mai interessate ai dati numerici, riguardano l'applicazione delle regole aziendali.
L'applicazione è in ibernazione / primavera e la mia strategia di test è la seguente:
- Ogni singola classe ottiene un test unitario. I collaboratori di ogni classe sono completamente derisi a questo punto e, per quanto ragionevole, il contratto di quella classe viene esercitato. Solitamente con casi di test scelti a mano. Questi test spesso vengono eseguiti in secondi.
- Un contesto in piena primavera viene attivato da TestNG. Sono quindi presenti tutti i collaboratori di una classe, e anche il livello di accesso al database è attivo (con un vero database su disco che viene eliminato nella parte finale del test). Ancora una volta, il sistema viene esercitato utilizzando test-case selezionati a mano. Il tempo di avvio di questi test spesso si estende in 20 - 30 secondi ciascuno, e ce ne sono abbastanza per incidere seriamente sui tempi di costruzione.
- Il sistema viene avviato, di solito contro un database vuoto e quindi una copia di un database dell'utente finale. Uno sviluppatore "fa clic attorno" a ciascun sistema avviato nel tentativo di ottenere un errore. Questo richiede un po 'di tempo, facilmente oltre 30 minuti.
Mi preoccupo che il mio regime di test sia insufficiente e che i miei test non siano efficaci come implicherebbero le loro metriche (è abbastanza facile avvicinarsi al 100% di copertura con questo schema). Non esiste una guida formale su come selezionare i casi di test, a parte "quelli che lo sviluppatore ritiene siano buoni test".
Ho considerato di provare a esprimere il comportamento del sistema in qualcosa di approssimativamente simile alla notazione Z , e usando quella specifica guidare la produzione di test case, ma è probabile che sia molto costoso in termini di tempo. Allo stesso modo, convincere i miei colleghi che ci sarà un ragionevole ritorno sull'investimento di tale attività sarebbe una vendita molto dura, e anche io non sono convinto che ne valga la pena per il nostro sistema.
Ci sono state discussioni relative a test randomizzati, ma sono stati vaghi e molto generali; e raramente ci imbattiamo in errori / eccezioni di run time (NullPointerException, ArraysOutOfBounds, ecc.), di solito il comportamento del sistema è inaccettabile per il client (vale a dire nei casi angolari / degenerati, il sistema si comporta in modo contro-intuitivo, ma che è completamente coerente)
Mi piacerebbe ottenere il massimo "bang for my buck" con i miei test; cioè, come si progettano i casi di test che potrebbero esercitare un difetto nei sistemi simili a quello sopra?