Keskustelu: Ohjelmointikysymykset: Java: Privaatti function JUnit-testaus?

Miten tällainen testataan JUnitilla?

private void calculatePages() {
     if (pageSize > 0) {
       // calculate how many pages there are
       if (list.size() % pageSize == 0) {
         maxPages = list.size() / pageSize;
       } else {
         maxPages = (list.size() / pageSize) + 1;
       }
   }
}

Sitähän ei voi noin vain JUnit-testata kun se on privaatti-functio..

Komponentteja ei kyllä pidä funktiotasolla testata vaan tarkoitus on varmistaa, että ne (= komponentit) tekevät sen asian, mikä niiden kuuluisikin. Sinun ei kuulu välittää lainkaan siitä, mitä komponentti tekee sisäisesti, kunhan sen tuottama lopputulos on oikein.

Kyseistä funktiota ei tarvitse testauttaa... tai jos tarvitsee, niin se ei saa olla private tai sitten se on jopa ihan väärässä paikassa. (Liian bloatti komponentti)

Vähän kuten Alchemist kirjoitti.

Jos kuitenkin haluat yksikkötestata tällaisen metodin, niin yksi vaihtoehto on tehdä siitä konfiguroitavissa oleva olio.

class Paginator {
    constructor(List list, Integer pageSize);
    Integer totalPages(); // calculatePages()

    Page nextPage();
    // jne.
}

Tällainen tyyli tekee komponenteista myös uudelleenkäytettäviä. Toki aina voidaan väitellä siitä, onko yleisesti mitään järkeä kirjoittaa yksikkötestejä jollekin näin triviaalille jutulle. Ja uudelleenkäytettävyys ei itsessään ole minkään arvoista (ts. tarvitaan myös niitä uudelleenkäyttäjiä).

Silloin kun niitä olioita tekee niin on toki hyvä tehdä niistä konffattavia.

Yksi vaihtoehto tässä tapauksessa olisi muuttaa testattava laskelma julkiseksi staattiseksi metodiksi.

// Testattava julkinen metodi:
public static int calculatePageCount(int listSize, int pageSize) {
  int maxPages = 0;
  // Tähän tulee metodin nykyinen sisältö.
  return maxPages;
}

// Sisäinen metodi vain käyttää julkista:
private void updatePageCount() {
  maxPages = calculatePageCount(list.size(), pageSize);
}

Mutta kuten The Alchemist totesi, triviaalia koodin osaa ei ole tarpeen yksikkötestata. Jos metodissa tosiaan lasketaan vain yksi jakolasku ylöspäin pyöristäen, voi ajatella, että koodi tulee tehtyä kerralla oikein. Muutenhan tulee järjetön määrä testejä suhteessa oikean koodin määrään, kun jokaisen peruslaskutoimituksen tulos ”testataan”.

Niin yritän vain saada koodirivien testaus % (tarkoitan Test Coverage) mahdollsimman isoksi. Mutta sitä ei ole kyllä tarpein saada 100 % kaikissa luokissa joita testaan.

Sellainen ongelma vaan, että testaus on vähän turhaa kuin Continous Integraatio -ohjelmistoni lisenssi on vuodelta 2011 ja teen Jira Appseja ja ks. ohjelmistoon ei saa Maven 3:sta sitten mitenkään asennettua puhumattakaan Atlassian SDK:sta niin en saa mitenkään päin koko Appsin lähdekoodia testatua. Eikä Polarion ALM -nimiseen ohjelmaan millä testauksen teen ihan vaan huvikseen opiskelumielessä tällä hekellä saa noita yllämainituja tämänkään vuoden versioon ja ohjelma maksoi minulle monta tonnia ja en pääse ohjelmasta eroon kun siellä on nyt monen vuoden ohjelmistokehityksen koko elinkaari SVN:ssä. En siis voi noin vain siirtä vaikka Atlassian Bamboohon ja Bitbuckettiin koska silloin monen tonnin sijoituksen Polarion ALM:n menee hukkaan.

walkout_ kirjoitti:

Niin yritän vain saada koodirivien testaus % (tarkoitan Test Coverage) mahdollsimman isoksi. Mutta sitä ei ole kyllä tarpein saada 100 % kaikissa luokissa joita testaan.

Jos testaat kattavasti julkista metodia joka käyttää sisäisesti tuota sisäistä metodia niin silloinhan sen pitäisi kaiken järjen mukaan olla laskettu jo Test Coverageen ja vaikka änkeisit sen vielä väkisin mukaan testeihin, niin sen ei pitäisi muuttaa prosenttia suuntaan tai toiseen.

walkout_ kirjoitti:

Niin yritän vain saada koodirivien testaus % (tarkoitan Test Coverage) mahdollsimman isoksi. Mutta sitä ei ole kyllä tarpein saada 100 % kaikissa luokissa joita testaan.

Jos tuo suoritetaan kun kutsutaan komponentin public rajapintaa JUnit niin se on mukava coverage% jo valmiina.