A JUnit tesztek alapvető építőelemei az állítások (assertion-ök), amelyek olyan logikai kifejezések, amik ha hamisak, az valamilyen hibát jelez. Az egyik legnagyobb hiba velük kapcsolatban az, ha kézi ellenőrzést végzünk. Ez általában úgy jelenik meg (innen ismerhetünk rá), hogy a tesztmetódus viszonylag sok utasítást tartalmaz, azonban állítást egyet sem. Ilyenkor a fejlesztő a tesztet elsősorban arra használja, hogy ha valamilyen hiba (például egy kivétel) a teszt végrehajtása során bekövetkezik, akkor kézzel elkezdhesse debugolni. Ez a megközelítés azonban pontosan a tesztautomatizálás lényegét és egyben legnagyobb előnyét veszi el, nevezetesen, hogy tesztjeinket a háttérben, minde külső beavatkozás nélkül kvázi folyamatosan futtassuk. A kézi ellenőrzések másik tünete, ha a tesztek viszonylag nagy mennyiségű adatot írnak a szabványos kimenetre vagy egy naplóba, majd ezeket kézzel ellenőrzik, hogy minden rendben zajlott-e. Ehhez nagyon hasonló ellenminta a hiányzó állítások esete, amikor egy tesztmetódus nem tartalmaz egyetlen utasítást sem. Ezek a helyzetek kerülendőek.

Nem csak a túl kevés, de a túl sok állítás is problémás lehet: ha egy tesztmetódusban több állítás is van, az általában azt jelenti, hogy a tesztmetódus túl sokat próbál tesztelni. Ezt orvosolhatjuk, ha szétvágjuk a tesztmetódust több tesztmetódusra.

// KERÜLENDŐ!
public class MyTestCase {

    @Test
    public void testSomething () {
        // Teszteset inicializálása, lokális változók manipulálása
        assertTrue (condition1);
        assertTrue (condition2);
        assertTrue (condition3);
    }
}

// JAVASOLT!
public class MyTestCase {
    // A lokális változókból példányváltozók lesznek

    @Before
    protected void setUp() {
        // Teszteset inicializálása, példányváltozók manipulálása
    }

    @Test
    public void testCondition1() {
        assertTrue(condition1);
    }

    @Test
    public void testCondition2() {
        assertTrue(condition2);
    }

    @Test
    public void testCondition3() {
        assertTrue(condition3);
    }
}

A redundáns feltételek szintén kerülendőek. Egy redundáns állítás egy olyan assert metódus, amelyben a feltétel beleégetett módon true. Általában ezzel a helyes működési mód demonstrálását szeretnék elvégezni, azonban a szükségtelen bőbeszédűség csak zsúfolttá teszi a metódust. Amennyiben egyéb állítások nincsenek is, akkor ez tulajdonképpen a kézzel ellenőrzés antimintával egyenértékű. Ha ilyennel találkozunk, egyszerűen csak szüntessük meg azon állításokat, amelyek a beégetett feltételt tartalmazzák.

//KERÜLENDŐ!
@Test
public void testSomething() {
    ...
    assertTrue("...", true);
}

A rossz állítás alkalmazása szintén problémát okozhat. Az Assert osztálynak elég sok metódusa kezdődik assert-tel, ráadásul sokszor csak kicsit eltérő közöttük a paraméterek száma és a szementikájuk. Sokan talán épp emiatt csupán egyetlen assert metódust használnak, mégpedig az assertTrue-t, és annak a logikai kifejezés részébe szuszakolják bele, hogy mit is szeretnének levizsgálni. Példák a rossz használatra:

assertTrue("Objects must be the same", expected == actual);
assertTrue("Objects must be equal", expected.equals(actual));
assertTrue("Object must be null", actual == null);
assertTrue("Object must not be null", actual != null);

Ezek helyett használjuk rendre az alábbiakat:

assertSame("Objects must be the same", expected, actual);
assertEquals("Objects must be equal", expected, actual);
assertNull("Object must be null", actual);
assertNotNull("Object must not be null", actual);

A kezdő egységtesztelők gyakorta csak valamilyen alapvető tesztkódot írnak, és nem vizsgálják meg teljesen a tesztelendő kódot. Ennek többféle megjelenési formája is van:

Ezek ellen valamilyen tesztlefedettség-mérő eszköz alkalmazásával védekezhetünk, amely segít meghatározni, hogy a kód melyik része nincs kielégítő módon tesztelve.

Az egységtesztek kódjának az éles rendszer kódjához hasonlóan könnyen érthetőnek kell lennie. Általánosságban azt mondhatjuk, hogy egy programozónak a lehető leggyorsabban meg kell értenie egy teszt célját. Ha egy teszt olyan bonyolult, hogy nem tudjuk azonnal megmondani róla, jó-e vagy sem, akkor nehéz megállapítani, hogy egy sikertelen tesztvégrehajtás a tesztelendő vagy a tesztelő kód rossz mivolta miatt következett-e be. Vagy ami még ennél is rosszabb, fennáll a lehetősége annak, hogy egy kód úgy megy át egy teszten, hogy nem volna neki szabad.

A túlbonyolított tesztek egyszerűsítését ugyanúgy végezzük, mint bármilyen más túlbonyolított kód egyszerűsítését: kódújraszervezést (refaktorálást) hajtunk végre a minél könnyebben érthető kód érdekében. Általában ezt a lépéssorozatot mindaddig végezzük, mígnem könnyen felismerhető módon a következő szerkezettel fog rendelkezni:

Annak érdekében, hogy a kód helyesen működjön, számos külső függőségre kell támaszkodnia, például függhet:

Az egységtesztek a tesztelési hierarchia legalsó szintjén helyezkednek el, a céljuk az, hogy kis mennyiségű kóddal izoláltan próbára tegyék az éles kód egy kis részét, vagyis az egységet. A magasabb szintű teszteléssel szemben az egységtesztelés célja tehát csakis önálló egységek ellenőrzése. Minél több függőségre van egy egységnek szüksége a futtatásához, annál nehezebb igazolni a megfelelő működést. Ha adatbázis-kapcsolatot kell konfigurálni, el kell indítani egy távoli szervert, stb., akkor az egységteszt futtatásáért nagy erőfeszítéseket kell tenni.

Az egységtesztek hatékonyságának jó mérőszáma, hogy egy kezdő fejlesztő mennyi idő alatt jut el a tesztek lefuttatásához onnantól kezdve, hogy a verziókezelő rendszerből beszerezte a kódokat. A legegyszerűbb megoldás a verziókezelőből (például cvs, svn vagy git) történő checkout után a build-elést végző eszköz (például ant vagy maven) futtatása, amely csak akkor megy ilyen egyszerűen, ha nincsenek külső függőségek. Ökölszabály, hogy a külső függőségeket el kell kerülni.

Ennek érdekében az alábbiakat tehetjük:

Míg az éles kód írásakor a fejlesztők általában tudatában vannak az el nem kapott kivételek problémáinak, ezért elég szorgalmasan elkapogatják és naplózzák a problémákat, azonban egységtesztelés esetén ez a minta teljességgel rossz!

Tekintsük az alábbi tesztmetódust::

// KERÜLENDŐ!
@Test
public void testCalculation () {
    try  {         
        deepThought.calculate();
        assertEquals("Calculation wrong", 42, deepThought.getResult());
    } catch (CalculationException ex) {
        Log.error("Calculation caused exception", ex);
    }
}

Ez teljesen rossz, hiszen a teszt átmegy akkor is, ha kiváltódott egy kivétel! Persze a napló bejegyzéseinek a vizsgálatával a problémára fény derülhet, de egy automatizált tesztelési környezetben gyakran senki nem olvassa a naplókat.

Még ennél is agyafúrtabb példát láthatunk itt:

// KERÜLENDŐ!
@Test
public void testCalculation() {
    try {
        deepThought.calculate();
        assertEquals("Calculation wrong", 42, deepThought.getResult());
    }
    catch(CalculationException ex) {
        fail("Calculation caused exception");
    }
}

Habár ez a példa annak rendje és módja szerint elbukik, és így jelzi a JUnit futtatónak, hogy valamivel hiba történt, a hiba helyét jelző aktuális veremtartalom elvész.

A megoldás az lesz, hogy ne kapjuk el a nem várt kivételeket! Hacsaknem direkt azért írunk kivételkezelőt, hogy ellenőrizzük, hogy egy eldobandó kivétel dobása tényleg megtörténik, nincs okunk elkapni a kivételeket. Sokkal inkább tovább kellene adni a hívási láncot a JUnit-nak, hogy kezelje ő. Az átalakított kód valahogy így nézhet ki:

@Test
public void testCalculation() throws CalculationException {
    deepThought.calculate();
    assertEquals("Calculation wrong", 42, deepThought.getResult());
}

Mint látható, eltűnt a try-blokk és megjelent egy throws utasításrész, a kód pedig könnybben olvashatóvá vált.

Amennyiben azt kellene igazolnunk, hogy egy adott kivétel bekövetkezik, akkor azt megtehetnénk többféleképpen is. Az első példában lévő teszteset csak akkor nem bukik el, ha a kivétel bekövetkezik.

@Test
public void testIndexOutOfBoundsException() {
    try {
        ArrayList emptyList = new ArrayList();
        Object o = emptyList.get(0);
        fail("Exception was not thrown");
    }
    catch(IndexOutOfBoundsException ex) {
        // Siker!
    }
}

A második példában ugyanerre a Test annotáció expected paraméterét használjuk:

@Test(expected = IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
    ArrayList emptyList = new ArrayList();
    Object o = emptyList.get(0);
    fail("Exception was not thrown");
}

A rossz helyre szervezett tesztkódok zavart okozhatnak. Tekintsük az alábbi elhelyezést, ahol a tesztosztály ugyanabban a könyvtárban helyezkedik el, mint a tesztelendő osztály:

src/
  com/
    xyz/
      SomeClass.java
      SomeClassTest.java

Ekkor nehéz megkülönböztetni a tesztkódot az alkalmazás kódjától. Ezen persze egy elnevezési konvencióval valamennyire lehet segíteni, azonban a tesztkódnak sokszor olyan segédosztályok is részét képezik, amelyek nem közvetlenül kerülnek tesztként futtatásra, csak felhasználják őket a tesztek.

Egy másik rossz elhelyezés:, ha a tesztjeinket egy alkönyvtárba helyezzük a tesztelendő kód alá.

src/
  com/
    xyz/
      SomeClass.java
      test/
         SomeClassTest.java

Ezzel egyszerűbb kitalálni, hogy melyik osztályra van a szükség a teszteléshez, és melyik az alkalmazás része, azonban a protected és csomag szintű láthatósággal rendelkező tagok tesztelésének búcsút inthetünk. Hacsaknem a teszt kedvéért kinyitjuk a hozzáférést, ami viszont megöli a bezárást.

Ráadásul mindkét megoldás további pluszmunkát ró ránk a szoftver kiadásának elkészítésekor, hiszen az egységteszt kódját nem telepítjük az éles rendszerre, épp ezért a csomagolás során valahogyan ki kell zárnunk a tesztelésre használatos kódunkat, ami az alkalmazott elnevezési konvenciótól függően akár elég byonyolult dolog is lehet.

A megoldás az, hogy a tesztkódokat ugyanabba a csomagba, de mégis eltérő (párhuzamos) hierarchiába tegyük. Ekkor könnyen szétválaszthatóak az éles kódok a tesztkódoktól és a bezárás megsértésének problémája sem lép fel, hiszen a tesztkód ugyanabban a csomagban helyezkedik el, mint a tesztelendő, ezért annak osztály szintű és protected tagjait is tesztelni tudja.

src/
  com/
    xyz/
      SomeClass.java
test/
  com/
    xyz/
      SomeClassTest.java

Ez esetben nem magukkal a tesztekkel, hanem azok hiányával van a baj. Minden programozó tudja, hogy teszteket kellene írnia a kódjához, mégis kevesen teszik. Ha megkérdezik tőlük, miért nem írnak teszteket, ráfogják a sietségre. Ez azonban ördögi körhöz vezet: minél nagyobb nyomást érzünk, annál kevesebb tesztet írunk. Minél kevesebb tesztet írunk, annál kevésbé leszünk produktívak és a kódunk is annál kevésbé lesz stabil. Minél kevésbé vagyunk produktívak és precízek, annál nagyobb nyomást érzünk magunkon. Ezt a problémát elhárítani csak úgy tudjuk, ha teszteket írunk. Komolyan. Annak ellenőrzése, hogy valami jól működik, nem szabad, hogy a végfelhasználóra maradjon. Az egységtesztelés egy hosszú folyamat első lépéseként tekintendő.

Azon túlmenően, hogy az egységtesztek a tesztvezérelt fejlesztés alapkövei, gyakorlatilag minden fejlesztési módszertan profitálhat a tesztek meglétéből, hiszen segítenek megmutatni, hogy a kódújraszervezési lépések nem változtattak a funkcionalitáson, és bizonyíthatják, hogy az API használható. Tanulmányok igazolták, hogy az egységtesztek használata drasztikusan növelni tudja a szoftverminőséget.