Prova online livello base java. Test del programma, JUnit. Prerequisiti del test Java

Credo che lo sviluppo del software sia più di un lavoro. Mi vedo come un artigiano che cerca di essere migliore ogni giorno. Il modo "più semplice" per farlo è trovare alcuni buoni strumenti e rispondere alle seguenti domande:

• Quando dovrei usare lo strumento X?
• Come dovrei usare lo strumento X?

I test automatizzati sono una parte molto importante dello sviluppo del software, ma ci sono pochi post sui blog dei programmatori sugli strumenti utilizzati. Lo stesso articolo ti permetterà di guardare nella mia "cassetta degli attrezzi". Tratterò 12 librerie e framework che utilizzo per scrivere unit test e test di integrazione e fornirò collegamenti a pagine per aiutarti a capire come usarli.

Diamo un'occhiata alla mia cassetta degli attrezzi

Prima di poter utilizzare gli strumenti descritti di seguito, è necessario configurare una build che esegua automaticamente l'integrazione e gli unit test. Ho 2 note su questo argomento:

• I test di integrazione con Maven descrivono come possiamo configurare una build Maven con integrazione e unit test in directory separate.
• Guida introduttiva a Gradle: test di integrazione con il plug-in TestSets descrive lo stesso per Gradle.

Ora sei pronto per dare un'occhiata più da vicino ai miei strumenti. Li ho divisi in categorie per facilitare la navigazione.

Quindi ecco 12 strumenti che utilizzo per l'integrazione e il test unitario.

Test in esecuzione

AssertJ fornisce un'API flessibile per la scrittura di asserzioni con messaggi di errore utili, migliora la leggibilità del codice di test e consente di trasformare i test in specifiche eseguibili che aderiscono al linguaggio specifico del dominio desiderato.

Inoltre:

• Using Hamcrest for Testing spiega come utilizzare Hamcrest per scrivere test e come estenderlo con moduli personalizzati.
• Trasformare le asserzioni in un linguaggio specifico del dominio spiega come creare asserzioni personalizzate in AssertJ.
• Scrittura di test puri: sostituzione di asserzioni con un linguaggio specifico del dominio. Spiega perché dovremmo sostituire le asserzioni JUnit standard con le nostre che utilizzano il linguaggio specifico del dominio corretto.

Test del codice di accesso ai dati

DB veloce, utile per scrivere test di integrazione che girano su macchina locale sviluppatore.

Un'estensione di JUnit che può essere utilizzata per inizializzare il database su uno stato noto prima di eseguire ogni test di integrazione e popolare il database con i dati desiderati. DbUnit ha i suoi svantaggi, ma è molto attrezzo utile A che consente di separare i dati di test e il codice di test.

Inoltre:

• descrive i componenti chiave di DbUnit che è necessario conoscere per scrivere test utilizzando DbUnit.
• fornisce cinque regole per scrivere i migliori test per il codice di accesso ai dati.

Alla ricerca di attività di test per programmatori Java, mi sono imbattuto in un sito interessante (gli utenti Avast non dovrebbero andare, viene rilevato un trojan con script, il resto apparentemente può farlo) - http://www.betterprogrammer.com. Controlla le qualifiche dei programmatori Java con il più semplice, ma automaticamente: offrendo di scrivere diverse funzioni (metodi) di crescente complessità e copiare il codice nella TextArea. Successivamente, il motore del sito fa qualcosa con i compiti (niente altro che test unitari), calcola un certo indice di qualificazione in base ai criteri di "velocità-qualità" e fornisce la valutazione finale in questa forma:

Poi iniziano le domande. Io stesso ho programmato in Java per la seconda volta nella mia vita (e quindi ho appena saltato compiti complessi), quindi l'82% di questo test corrisponde al livello programmatore non Java. Quanto dovrebbero quindi ottenere Java Junior, Java Programmer e ancor di più Java Senior? Da quale risultato aspettarsi presente programmatore java - 90, 95, 99? E infine, cosa succede se il "programmatore" ottiene un punteggio inferiore a 82, ma fa comunque domanda per qualche tipo di lavoro?!

I test non sono sempre divertenti e interessanti. Questo processo è solitamente piuttosto lungo e talvolta pieno di lavoro monotono. Sembra che recentemente i programmatori abbiano utilizzato l'output standard o un debugger per testare le classi Java.

In questo articolo descriverò la libreria JUnit 4, che semplifica e automatizza notevolmente il processo di scrittura dei test.

Per dimostrare le caratteristiche principali di JUnit Framework, scriviamo una classe primitiva in Java e modelliamola. Questa classe avrà due metodi: trovare il fattoriale di un numero non negativo e la somma di due numeri. Inoltre, l'istanza della classe conterrà un contatore di chiamate al metodo.

Public class MathFunc ( int chiamate; public int getCalls() ( return chiamate; ) public long fattoriale(int numero) ( chiamate++; if (numero 1) ( for (int i = 1; i

Ora scriviamo i test unitari. Per fare ciò, creiamo una classe con un numero di metodi di test. Naturalmente una classe può contenere anche i soliti metodi helper. Affinché il test runner possa determinare chi è chi, i metodi di test devono essere annotati con l'annotazione @Test.

L'annotazione può avere i seguenti parametri:

• atteso - specificare quale eccezione verrà generata dal metodo (vedere l'esempio seguente);
• timeout - dopo quanto tempo in millisecondi interrompere l'esecuzione del test e contarlo come non riuscito.

Se vuoi indicare che un determinato test deve essere saltato, annotalo con l'annotazione @Ignore. Sebbene tu possa semplicemente rimuovere l'annotazione @Test.

Succede che hai bisogno di un contesto, ad esempio istanze di classe pre-create, per eseguire ogni scenario di test. E dopo l'esecuzione, devi rilasciare le risorse riservate. In questo caso, avrai bisogno delle annotazioni @Before e @After. Un metodo contrassegnato con @Before verrà eseguito prima di ogni test case e un metodo contrassegnato con @After verrà eseguito dopo ogni test case.

Se l'inizializzazione e il rilascio delle risorse devono essere eseguiti solo una volta, rispettivamente prima e dopo tutti i test, utilizzare una coppia di annotazioni @BeforeClass e @AfterClass.

Ed ecco la classe di test stessa con diversi script di test:

Public class MathFuncTest ( private MathFunc math; @Before public void init() ( math = new MathFunc(); ) @After public void tearDown() ( math = null; ) @Test public void calls() ( assertEquals(0, math.getCalls()); math.factorial(1); assertEquals(1, math.getCalls()); math.factorial(1); assertEquals(2, math .getCalls()); ) @Test public void factorial() ( assertTrue(math.factorial(0) == 1); assertTrue(math.factorial(1) == 1); assertTrue(math.factorial(5) == 120); ) @Test(expected = IllegalArgumentException.class) public void factorialNegative() ( math.factorial(-1); ) @Ignore @Test public void todo() ( assertTrue(math.plus(1, 1) == 3); ) )

Il metodo delle chiamate verifica la correttezza del contatore delle chiamate. Il metodo fattoriale verifica se il fattoriale è calcolato correttamente per alcuni valori standard. Il metodo factorialNegative verifica che venga lanciata una IllegalArgumentException per i valori negativi del facotrial. Il metodo todo verrà ignorato. Prova a rimuovere l'annotazione @Ignore mentre fai esperimenti con il codice.

Il metodo assertTrue controlla se il risultato di un'espressione è vero. Alcuni altri metodi che potrebbero tornare utili:

• assertEquals - il risultato atteso e il risultato ricevuto sono gli stessi;
• assertNull - il risultato dell'espressione è nullo;
• assertNotNull - il risultato dell'espressione non è nullo;
• assertSame: gli oggetti previsti e ricevuti sono lo stesso oggetto.
• fail - il metodo genera un'eccezione AssertionError - la aggiungiamo dove l'esecuzione del programma non dovrebbe arrivare.

Nel nostro mondo moderno Gli IDE possono trovare ed eseguire facilmente i test in un progetto. Ma cosa succede se si desidera eseguirli manualmente utilizzando il codice del programma. Per fare ciò, puoi usare Runner "th. Ci sono testo - junit.textui.TestRunner, versioni grafiche - junit.swingui.TestRunner, junit.awtui.TestRunner.

Ma un po' di più metodo modernoè l'uso della classe JUnitCore. Aggiungere il seguente metodo principale alla classe MathFuncTest:

Public static void main(String args) genera un'eccezione ( JUnitCore runner = new JUnitCore(); Result result = runner.run(MathFuncTest.class); System.out.println("run tests: " + result.getRunCount()); System.out.println("failed tests: " + result.getFailureCount()); System.out.println("ignored tests: " + result.getIgnoreCount()); System.out.println("success: " + result.wasSuccessful()); )

E il risultato dell'esecuzione:

Esegui test: 3 test falliti: 0 test ignorati: 1 riuscito: vero

Nelle versioni precedenti di JUnit, per scrivere una classe di test era necessario creare una sottoclasse di junit.framework.TestCase. Poi è stato necessario definire un costruttore che prende come parametro una String - il nome del metodo - e lo passa alla classe genitore. Ogni metodo di test doveva iniziare con il prefisso del test. I metodi setUp e tearDown sono stati utilizzati per inizializzare e rilasciare le risorse. Insomma, orrore. Bene, ora tutto è semplice, sì.

È tutto per oggi. Sono sicuro che JUnit Framework ti aiuterà molto. Commenti e domande sull'articolo sono i benvenuti.