tifyty

pure Java, what else ?

Egy kis tesztelés

A Behaviour Driven Development módszertanban szokás, hogy a teszt kód alapja

  • GIVEN
  • WHEN
  • THEN

alakú. Még a Mockitónak is van DBBMockito façade implementációja, ami ehhez a szokáshoz igazodik. Sőt ha valaki akar egy nagyágyút, nos ott a JBehave. De most csak egy sima kis unit teszt:

    private static final Configuration config = new BasicConfiguration();
    private static final String key = "key";
    private static final String value = "value";
    private static final String badValue = "badValue";
...
    public void testGetConfigValueWhenEnvironmentKeyExists() {
        String actual;
        Properties props;
        // GIVEN
        props = PowerMockito.mock(Properties.class);
        PowerMockito.mockStatic(System.class);
        config.setConfigProperties(props);
        Mockito.when(props.containsKey(key)).thenReturn(true);
        Mockito.when(props.getProperty(key)).thenReturn(badValue);
        Mockito.when(System.getenv("sb4j." + key)).thenReturn(value);
        // WHEN
        actual = config.getConfigValue(key);
        // THEN
        Mockito.verify(props).containsKey(key);
        Mockito.verify(props).getProperty(key);
        PowerMockito.verifyStatic();
        System.getenv("sb4j." + key);
        Assert.assertEquals(value, actual);
    }

Nem érzel valami bizsergést, hogy ez így nem az igazi? Mi az a három komment? Ha egy metódusba kommentet akarok írni, bele a belsejébe, akkor mindig elgondolkodom rajta, hogy miért is? Mi történt? Miért olyan bonyolult ez a metódus, hogy fel kell kommentezni? Persze, ja, hogyne… ki is vehetem azt a három sort, de attól nem lesz jobb, maximum átmenetileg tisztább, szárazabb az érzés, de a görcs megmarad.

Mi lenne, ha egy baromi egyszerű, kis Business class-t készítenénk, és átszállnánk a turista osztályról. Nem is kell teljesen elkészíteni, félbe is hagyhatjuk:

public abstract class Business {

    abstract public void given();
    abstract public void when();
    abstract public void then();
    public void execute(){
        given();
        when();
        then();
    }
    
}

Ez igazán nem sok, minden projektbe belefér. És ha ez megvan, akkor a teszt már sokkal szebb:

    @Test
    public void testGetConfigValueWhenEnvironmentKeyExists() {
        new Business() {
            private String actual;
            private Properties props;

            @Override
            public void given() {
                props = PowerMockito.mock(Properties.class);
                PowerMockito.mockStatic(System.class);
                config.setConfigProperties(props);
                Mockito.when(props.containsKey(key)).thenReturn(true);
                Mockito.when(props.getProperty(key)).thenReturn(badValue);
                Mockito.when(System.getenv("sb4j." + key)).thenReturn(value);
            }

            @Override
            public void when() {
                actual = config.getConfigValue(key);
            }

            @Override
            public void then() {
                Mockito.verify(props).containsKey(key);
                Mockito.verify(props).getProperty(key);
                PowerMockito.verifyStatic();
                System.getenv("sb4j." + key);
                Assert.assertEquals(value, actual);
            }

        }.execute();
    }

Ugye mennyivel szebb? Már csak egy kérdés maradt: hogy sikerült a System final osztályt statikusan mockolni a powermock-kal? De ez már egy másik történet, ráment négy óra. Most hétvégére legyen csak egy ilyen könnyű cikk, jövő hétre a csőben van egy kis kivételkezelési sebesség, de utána elmondom, hogy hogyan is tud működni ez a teszt. Lesz benne classloader, maven, eclipse … “és kakast is!”.

8 responses to “Egy kis tesztelés

  1. rlegendi augusztus 3, 2012 2:40 du.

    Nem keverjük a Business Driven Developmentet a Behaviour Driven Developmenttel?

    http://en.wikipedia.org/wiki/Behavior-driven_development

  2. István Verhás (@verhasi) augusztus 3, 2012 2:50 du.

    A “Assert.assertEquals(value, actual);” value-t nem kéne deklarálni meg esetleg értéket adni neki?

  3. Timpala augusztus 16, 2012 11:00 de.

    Még szebb lenne a történt ha tetszene használni import staticot. Egyébként frameworkot írni teszteléshez(igen ez már annak számít) nem túl szerencsés, de talán ez az apróság még belefér.

  4. Takacs Otto július 24, 2013 10:45 de.

    hmm jó régi, de….

    Van egy fontos aspektusa a BDD-nek az pedig az, hogy a tesztnek elsősorban könnyen olvashatónak kell lennie (a könnyen írhatóság helyett). A Fenti példa nagyon rossz, mivel semmi infó nincs, hogy tényleges miről is szól. (framework ide vagy oda)

    Sokkal hasznosabb egy ilyen struktúra (példa):

      @Test
      public void user_field_empty() throws Exception {
        given_empty_user_id();
        given_user_text("otto");
        when_validate();
        then_got_error_message("qwerty");
      }
    // metódus implementációk...
    

    Ugyan az az eszközrendszer, ugyan az a struktúra, de ez inkább BDD, mint a példa fentebb, hiszen könnyebben olvasható.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: