Tiešsaistes testa java sākuma līmenis. Programmas testēšana, JUnit. Java testa priekšnoteikumi

Es uzskatu, ka programmatūras izstrāde ir vairāk nekā darbs. Es sevi redzu kā amatnieku, kurš katru dienu cenšas būt labāks. "Vienkāršākais" veids, kā to izdarīt, ir atrast dažus labus rīkus un atbildēt uz šādiem jautājumiem:

• Kad man vajadzētu izmantot X rīku?
• Kā lietot rīku X?

Automatizētā testēšana ir ļoti svarīga programmatūras izstrādes sastāvdaļa, taču programmētāju emuāros ir maz ierakstu par izmantotajiem rīkiem. Tas pats raksts ļaus ieskatīties manā "rīku kastē". Es apskatīšu 12 bibliotēkas un ietvarus, ko izmantoju vienību un integrācijas testu rakstīšanai, un sniegšu saites uz lapām, lai palīdzētu jums saprast, kā tās izmantot.

Ieskatīsimies manā instrumentu kastē

Lai varētu izmantot tālāk aprakstītos rīkus, jums ir jāiestata būvējums, kas automātiski palaiž integrācijas un vienību pārbaudes. Man ir 2 piezīmes par šo tēmu:

• Integrācijas testēšana ar Maven apraksta, kā mēs varam iestatīt Maven būvējumu ar integrāciju un vienību testiem atsevišķos direktorijos.
• Darba sākšana ar Gradle: Integrācijas pārbaude ar TestSets spraudni apraksta to pašu Gradle.

Tagad esat gatavs tuvāk apskatīt manus rīkus. Esmu tos sadalījis kategorijās, lai jums būtu vieglāk orientēties.

Tātad šeit ir 12 rīki, ko izmantoju integrācijai un vienību testēšanai.

Skriešanas testi

AssertJ nodrošina elastīgu API apgalvojumu rakstīšanai ar noderīgiem kļūdu ziņojumiem, uzlabo testa koda lasāmību un ļauj pārvērst testus izpildāmās specifikācijās, kas atbilst vēlamajai domēna valodai.

Papildus:

• Izmantojot Hamcrest testēšanai, ir paskaidrots, kā izmantot Hamcrest testu rakstīšanai un kā to paplašināt ar pielāgotiem moduļiem.
• Apgalvojumu pārvēršana domēnam specifiskā valodā izskaidro, kā programmā AssertJ izveidot pielāgotus apgalvojumus.
• Tīro testu rakstīšana: apgalvojumu aizstāšana ar domēnam specifisku valodu. Izskaidro, kāpēc standarta JUnit apgalvojumi ir jāaizstāj ar saviem apgalvojumiem, kuros tiek izmantota pareizā domēna valoda.

Datu piekļuves koda pārbaude

Ātra DB, noderīga, lai rakstītu integrācijas testus, kas darbojas vietējā mašīna izstrādātājs.

JUnit paplašinājums, ko var izmantot, lai inicializētu datubāzi zināmā stāvoklī pirms katras integrācijas pārbaudes izpildes un datu bāzes aizpildīšanas ar vajadzīgajiem datiem. DbUnit ir savi trūkumi, taču tas ir ļoti noderīgs rīks A, kas ļauj atdalīt testa datus un testa kodu.

Papildus:

• apraksta galvenās DbUnit sastāvdaļas, kas jums jāzina, lai rakstītu testus, izmantojot DbUnit.
• nodrošina piecus noteikumus labāko datu piekļuves koda testu rakstīšanai.

Meklējot testa uzdevumus java programmētājiem, es uzgāju interesantu vietni (Avast lietotājiem nevajadzētu iet, tiek atklāts skripts Trojas zirgs, pārējais acīmredzot var) - http://www.betterprogrammer.com. Tas pārbauda Java programmētāju kvalifikāciju ar vienkāršāko, bet automātiski: piedāvājot uzrakstīt vairākas arvien sarežģītākas funkcijas (metodes) un iekopēt kodu TextArea. Tālāk vietnes dzinējs kaut ko veic ar uzdevumiem (nevienu citu kā vienību testēšanu), aprēķina noteiktu kvalifikācijas indeksu atbilstoši "ātruma kvalitātes" kritērijiem un sniedz gala novērtējumu šādā formā:

Tad sākas jautājumi. Es pats otro reizi mūžā programmēju Java (un tāpēc vienkārši izlaidu sarežģītus uzdevumus), tāpēc 82% šajā testā atbilst līmenim programmētājs, kas nav Java programmētājs. Cik tad vajadzētu saņemt Java Junior, Java Programmer un vēl jo vairāk Java Senior? Kādu rezultātu gaidīt klāt java programmētājs - 90, 95, 99? Un visbeidzot, ja nu "programmētājs" saņem mazāk par 82, bet tomēr piesakās uz kādu darbu?!

Testēšana ne vienmēr ir jautra un interesanta. Šis process parasti ir diezgan ilgstošs un dažreiz pilns ar monotonu darbu. Šķiet, ka pavisam nesen programmētāji Java klašu pārbaudei izmantoja standarta izvadi vai atkļūdotāju.

Šajā rakstā es aprakstīšu JUnit 4 bibliotēku, kas ievērojami vienkāršo un automatizē testu rakstīšanas procesu.

Lai demonstrētu JUnit Framework galvenās iezīmes, uzrakstīsim primitīvu klasi Java valodā un izsmejam to. Šai klasei būs divas metodes – nenegatīva skaitļa faktoriāla atrašana un divu skaitļu summas atrašana. Turklāt klases instancē būs metodes izsaukuma skaitītājs.

Publiskā klase MathFunc ( int calls; public int getCalls() ( atgriešanās zvani; ) public long factorial(int number) ( calls++; if (skaitlis 1) ( for (int i = 1; i)

Tagad rakstīsim vienību testus. Lai to izdarītu, izveidosim klasi ar vairākām pārbaudes metodēm. Protams, klasē var būt arī parastās palīgmetodes. Lai testa dalībnieks varētu noteikt, kurš ir kurš, testa metodes ir jāanotē ar @Test anotāciju.

Anotācijai var būt šādi parametri:

• gaidīts - norādiet, kurš izņēmums tiks izmests ar metodi (skatiet piemēru zemāk);
• taimauts - pēc kāda laika milisekundēs apturēt testa izpildi un uzskatīt to par neveiksmīgu.

Ja vēlaties norādīt, ka kāds tests ir jāizlaiž, anotējiet to ar @Ignore anotāciju. Lai gan jūs varat vienkārši noņemt @Test anotāciju.

Gadās, ka katra testa scenārija izpildei ir nepieciešams kāds konteksts, piemēram, iepriekš izveidoti klases gadījumi. Un pēc izpildes jums ir jāatbrīvo rezervētie resursi. Šajā gadījumā jums būs nepieciešamas anotācijas @Pirms un @Pēc. Metode, kas atzīmēta ar @Before, tiks izpildīta pirms katra testa gadījuma, un metode, kas atzīmēta ar @Pēc, tiks izpildīta pēc katra testa gadījuma.

Ja resursu inicializācija un atbrīvošana ir jāveic tikai vienu reizi – attiecīgi pirms un pēc visām pārbaudēm, tad izmantojiet @BeforeClass un @AfterClass anotāciju pāri.

Un šeit ir pati testa klase ar vairākiem testa skriptiem:

Publiskā klase MathFuncTest ( privātā 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); ) )

Zvanu metode pārbauda zvanu skaitītāja pareizību. Faktoriāla metode pārbauda, ​​vai faktoriāls ir pareizi aprēķināts dažām standarta vērtībām. Faktoriālā negatīvā metode pārbauda, ​​vai negatīvām fakotriāla vērtībām tiks izmests Nelegālais arguments izņēmums. Todo metode tiks ignorēta. Eksperimentējot ar kodu, apsveriet iespēju noņemt @Ignore anotāciju.

Metode assertTrue pārbauda, ​​vai izteiksmes rezultāts ir patiess. Dažas citas metodes, kas varētu noderēt:

• assertEquals - paredzamais rezultāts un saņemtais rezultāts ir vienāds;
• assertNull - izteiksmes rezultāts ir null;
• assertNotNull - izteiksmes rezultāts nav nulle;
• assertSame - gaidītais un saņemtais objekts ir viens un tas pats objekts.
• fail - metode ģenerē AssertionError izņēmumu - mēs to pievienojam tur, kur programmas izpildei nevajadzētu sasniegt.

Mūsu mūsdienu pasaule IDE var atrast un viegli palaist testus projektā. Bet ko darīt, ja vēlaties tos palaist manuāli, izmantojot programmas kodu. Lai to izdarītu, varat izmantot Runner "th. Ir teksts - junit.textui.TestRunner, grafiskās versijas - junit.swingui.TestRunner, junit.awtui.TestRunner.

Bet nedaudz vairāk moderna metode ir JUnitCore klases izmantošana. Pievienojiet MathFuncTest klasei šādu galveno metodi:

Public static void main(String args) met Izņēmums ( JUnitCore runner = new JUnitCore(); Result result = runner.run(MathFuncTest.class); System.out.println("palaist testus: " + result.getRunCount()); System.out.println("neveiksmīgi testi: " + rezultāts.getFailureCount()); System.out.println("ignorētie testi: " + rezultāts.getIgnoreCount()); System.out.println("veiksmi: " + rezultāts .ws Successful()); )

Un izpildes rezultāts:

Izpildīt testus: 3 nesekmīgi testi: 0 ignorēti testi: 1 veiksmīgi: patiess

Vairāk agrīnās versijas JUnit, lai uzrakstītu testa klasi, bija nepieciešams izveidot junit.framework.TestCase pēcteci. Pēc tam bija jādefinē konstruktors, kas par parametru ņem String - metodes nosaukumu - un nodod to vecākajai klasei. Katrai pārbaudes metodei bija jāsākas ar testa prefiksu. Resursu inicializācijai un atbrīvošanai tika izmantotas iestatīšanas un nojaukšanas metodes. Īsāk sakot, šausmas. Nu, tagad viss ir vienkārši, jā.

Tas šodienai viss. Esmu pārliecināts, ka JUnit Framework jums ļoti palīdzēs. Ir laipni gaidīti komentāri un jautājumi par rakstu.