Hogyan lehet TDD-t megvalósítani egy Java-listán

1. Áttekintés

Ebben az oktatóanyagban végigvezetünk egy szokást Lista megvalósítás a tesztvezérelt fejlesztési (TDD) folyamat segítségével.

Ez nem egy bevezetés a TDD-hez, ezért feltételezzük, hogy már van néhány alapvető elképzelése arról, hogy mit jelent, és tartós érdeklődéssel javítani.

Egyszerűen fogalmazva, A TDD egy olyan tervezőeszköz, amely lehetővé teszi számunkra, hogy tesztek segítségével irányítsuk megvalósításunkat.

Gyors felelősség kizárása - itt nem a hatékony megvalósítás létrehozására koncentrálunk - csak ürügyként használjuk a TDD gyakorlatok megjelenítésére.

2. Az első lépések

Először határozzuk meg az osztályunk csontvázat:

public class A CustomList megvalósítja a {private Object [] internal = {} listát; // üres végrehajtási módszerek} 

A CustomList osztály hajtja végre a Lista interfész, ezért tartalmaznia kell az abban az interfészben deklarált összes módszer megvalósítását.

Az induláshoz csak üres testeket tudunk biztosítani ezekhez a módszerekhez. Ha egy metódusnak van visszatérési típusa, akkor tetszőleges ilyen típusú értéket adhatunk vissza, például nulla mert Tárgy vagy hamis mert logikai.

A rövidség kedvéért elhagyjuk az opcionális módszereket, valamint néhány olyan kötelező módszert, amelyeket nem gyakran használnak.

3. TDD ciklusok

Megvalósításunk fejlesztése a TDD-vel azt jelenti, hogy nekünk kell először hozzon létre teszteseteket, ezáltal meghatározva a megvalósításunk követelményeit. Csak majd létrehozzuk vagy kijavítjuk a megvalósítási kódot hogy ezek a tesztek sikeresek legyenek.

Nagyon leegyszerűsítve az egyes ciklusok három fő lépése a következő:

  1. Írás tesztek - meghatározza a követelményeket tesztek formájában
  2. Funkciók megvalósítása - hogy a tesztek sikeresek legyenek anélkül, hogy túlságosan a kód eleganciájára koncentrálnának
  3. Refaktorálás - javítsa a kódot, hogy megkönnyítse az olvasást és a karbantartást a tesztek teljesítése mellett

Végig fogjuk járni ezeket a TDD ciklusokat a Lista felület, kezdve a legegyszerűbbekkel.

4. A üres Módszer

A üres módszer valószínűleg a legegyszerűbb módszer, amelyet a Lista felület. Itt van a kezdő megvalósításunk:

@Orride public boolean isEmpty () {return false; }

Ez a kezdeti módszerdefiníció elég az összeállításhoz. Ennek a módszernek a teste javításra kényszerül, ha újabb és újabb teszteket adnak hozzá.

4.1. Az első ciklus

Írjuk meg az első tesztesetet, amely biztosítja, hogy a üres metódus visszatér igaz amikor a lista nem tartalmaz elemet:

@Test public void givenEmptyList_whenIsEmpty_thenTrueIsReturned () {List list = new CustomList (); assertTrue (list.isEmpty ()); }

Az adott teszt sikertelen, mivel üres metódus mindig visszatér hamis. Csak a visszatérési érték megfordításával tudjuk átadni:

@Orride public boolean isEmpty () {return true; }

4.2. A második ciklus

Annak megerősítésére, hogy a üres metódus visszatér hamis ha a lista nem üres, hozzá kell adnunk legalább egy elemet:

@Test public void givenNonEmptyList_whenIsEmpty_thenFalseIsReturned () {List list = new CustomList (); list.add (null); assertFalse (list.isEmpty ()); }

A hozzá módszerre van szükség. Itt van a hozzá módszerrel indulunk:

@Orride public boolean add (E elem) {return false; }

Ez a módszer nem működik, mivel a lista belső adatszerkezetében nem történik változás. Frissítsük a hozzáadott elem tárolására:

@Orride public boolean add (E element) {internal = new Object [] {element}; return false; }

Tesztünk még mindig nem sikerült, mivel üres A módszer nem lett továbbfejlesztve. Csináljuk meg:

@Orride public boolean isEmpty () {if (internal.length! = 0) {return false; } else {return true; }}

A nem üres teszt ezen a ponton teljesül.

4.3. Refaktorálás

Mindkét teszteset, amelyet eddig láttunk, megfelelt, de a üres módszer elegánsabb lehet.

Tegyük refaktorrá:

@Orride public boolean isEmpty () {return internal.length == 0; }

Láthatjuk, hogy a tesztek sikeresek, így a üres módszer teljes.

5. A méret Módszer

Ezzel kezdjük a méret metódus a CustomList osztály összeállításához:

@Orride public int size () {return 0; }

5.1. Az első ciklus

A meglévő felhasználásával hozzá módszerrel létrehozhatjuk az első tesztet a méret metódus, annak ellenőrzése, hogy az egyetlen elemet tartalmazó lista mérete 1:

@Test public void givenListWithAnElement_whenSize_thenOneIsReturned () {List list = new CustomList (); list.add (null); assertEquals (1, list.size ()); }

A teszt sikertelen, mivel méret módszer visszatér 0. Tegyük át egy új megvalósítással:

@Orride public int size () {if (isEmpty ()) {return 0; } else {return internal.length; }}

5.2. Refaktorálás

Refaktorálhatjuk a méret módszer elegánsabbá tételéhez:

@Orride public int size () {return internal.length; }

Ennek a módszernek a megvalósítása befejeződött.

6. A kap Módszer

Itt van a kap:

@Orride public E get (int index) {return null; }

6.1. Az első ciklus

Vizsgáljuk meg ennek a módszernek az első tesztjét, amely ellenőrzi a lista egyetlen elemének értékét:

@Test public void givenListWithAnElement_whenGet_thenThatElementIsReturned () {List list = new CustomList (); list.add ("baeldung"); Object element = list.get (0); assertEquals ("baeldung", elem); }

A teszt a kap módszer:

@Orride public E get (int index) {return (E) internal [0]; }

6.2. Javulás

Általában további teszteket adunk hozzá, mielőtt további fejlesztéseket hajtanánk végre a kap módszer. Ezeknek a teszteknek más módszerekre lenne szükségük Lista interfész a megfelelő állítások megvalósításához.

Ezek a más módszerek azonban még nem elég kiforrottak, ezért megszakítjuk a TDD ciklust, és létrehozzuk a kap módszer, ami valójában nem túl nehéz.

Ezt könnyű elképzelni kap ki kell vonni egy elemet a belső tömb a megadott helyen a index paraméter:

@Orride public E get (int index) {return (E) belső [index]; }

7. Az hozzá Módszer

Ez a hozzá a 4. szakaszban létrehozott módszer:

@Orride public boolean add (E element) {internal = new Object [] {element}; return false; }

7.1. Az első ciklus

Az alábbiakban bemutatunk egy egyszerű tesztet, amely ellenőrzi a hozzá:

@Test public void givenEmptyList_whenElementIsAdded_thenGetReturnsThatElement () {List list = new CustomList (); logikai sikertelen = list.add (null); assertTrue (sikerült); }

Módosítanunk kell a hozzá módszer a visszatéréshez igaz a teszt sikeres teljesítéséhez:

@Orride public boolean add (E element) {internal = new Object [] {element}; return true; }

Bár a teszt sikeres, a hozzá módszer még nem terjed ki minden esetre. Ha hozzáadunk egy második elemet a listához, a meglévő elem elvész.

7.2. A második ciklus

Itt van egy másik teszt, amely megköveteli, hogy a lista egynél több elemet tartalmazhasson:

@Test public void givenListWithAnElement_whenAnotherIsAdded_thenGetReturnsBoth () {List list = new CustomList (); list.add ("baeldung"); list.add (". com"); Object element1 = list.get (0); Object element2 = list.get (1); assertEquals ("baeldung", elem1); assertEquals (". com", elem2); }

A teszt nem fog sikerülni a hozzá A módszer a jelenlegi formájában nem engedélyez egynél több elem hozzáadását.

Változtassuk meg a megvalósítási kódot:

@Orride public boolean add (E element) {Object [] temp = Arrays.copyOf (belső, belső.hossz + 1); temp [belső.hossz] = elem; belső = hőmérséklet; return true; }

A megvalósítás elég elegáns, ezért nem kell átalakítanunk.

8. Következtetés

Ez az oktatópróba által vezérelt fejlesztési folyamaton ment keresztül egy egyedi rész létrehozása érdekében Lista végrehajtás. A TDD segítségével lépésről lépésre tudjuk megvalósítani a követelményeket, miközben a teszt lefedettségét nagyon magas szinten tartjuk. A megvalósítás garantáltan tesztelhető is, mivel a tesztek sikeres áthaladására hozták létre.

Vegye figyelembe, hogy az ebben a cikkben létrehozott egyéni osztály csak bemutató célokra használható, és nem szabad egy valós projektben elfogadni.

Az oktatóanyag teljes forráskódja, beleértve a rövidítés érdekében kihagyott tesztelési és megvalósítási módszereket, a GitHub oldalon található.


$config[zx-auto] not found$config[zx-overlay] not found