Wątek przeniesiony 2020-03-08 22:38 z Java przez Shalom.

Granice testów jednostkowych

1

W Twoim przypadku jeśli doszło by do jeszcze kilku innych warunków to przecież żeby każdą ścieżkę przerobić byłoby potrzebne tysiące testów

To znaczy ze masz *ujowy design jak masz milion warunków ;)

Przecież mam test, który sprawdza widok w kilku przypadkach

W kilku wybranych xD sprawdzasz kro i mer a innych już nie. Jakiś geniusz wywalił przypadkiem obsługę pozostałych a ty nawet o tym nie wiesz :D

Mógłbyś pokazać przykład takiego sparametryzowanego testu na moim przykładzie jak to powinno wyglądać według Ciebie?

Serio? Przecież widzisz że wszystkie te testy wyglądają identyczne. Zrób w takim razie argumenty do nich...

0
Shalom napisał(a):

W Twoim przypadku jeśli doszło by do jeszcze kilku innych warunków to przecież żeby każdą ścieżkę przerobić byłoby potrzebne tysiące testów

To znaczy ze masz *ujowy design jak masz milion warunków ;)

To mógłbyś pokazać na podanym przykładzie jak to zrobić inaczej?

Przecież mam test, który sprawdza widok w kilku przypadkach

W kilku wybranych xD sprawdzasz kro i mer a innych już nie. Jakiś geniusz wywalił przypadkiem obsługę pozostałych a ty nawet o tym nie wiesz :D

Przecież właśnie po to jest osobny test, który sprawdzi czy wszystko działa. Owszem ten jeden test dla kro przejdzie a inne się wywalą jak ktoś sknoci i wiemy, że działa/nie działa dzięki temu.

Mógłbyś pokazać przykład takiego sparametryzowanego testu na moim przykładzie jak to powinno wyglądać według Ciebie?

Serio? Przecież widzisz że wszystkie te testy wyglądają identyczne. Zrób w takim razie argumenty do nich...

To jak rozwiązałbyś tu nazewnictwo? Przecież subtesty nie będą miały swojej nazwy w takim przypadku?

0

@anonimowy: Wersja easy:

public class AdditionTest {

    public long add(long a, long b){
        return a + b;
    }

    @Test
    void shouldAddZeros(){
        testAdd(0, 0, 0);
    }

    @Test
    void shouldAddNegatives(){
        testAdd(-5, -5, -10);
    }

    void testAdd(long a, long b, long expectedResult){
        long result = add(a, b);
        Assertions.assertThat(result).isEqualTo(expectedResult);
    }
}

Wersja JUnit5 + Enum:

public class AdditionTest {

    public long add(long a, long b){
        return a + b;
    }

    enum Scenario {
        ZEROS(0 , 0, 0),
        NEGATIVES(-5, -5, -10);

        Scenario(long first, long second, long expectedResult) {
            this.first = first;
            this.second = second;
            this.expectedResult = expectedResult;
        }

        long first;
        long second;
        long expectedResult;
    }

    @ParameterizedTest
    @EnumSource(Scenario.class)
    void shouldAddCorrectlyAllScenarios(Scenario scenario){
        long result = add(scenario.first, scenario.second);
        Assertions.assertThat(result).isEqualTo(scenario.expectedResult);
    }
}
0

Pisanie w JUnit to nieporozumienie :P
Wersja Spock:

class AdditionTest extends Specification {

    long add(long a, long b) {
        return a + b;
    }

    @Unroll("#a + #b = #sum")
    def "Should add two numbers"() {
        expect:
        add(a, b) == sum

        where:
        a  | b  | sum
        1  | 2  | 3
        0  | 0  | 0
        -5 | -5 | -10
    }
}
0

No dobrze na trywialnym przykładzie to może działać ale w przypadku zagmatwanej logiki biznesowej gdzie musisz ustawiać różnie dane w bazie nie do końca można to sparametryzować

0

IMO testy jednostkowe trzeba pisać tak, aby wykonanie wszystkich testów jednostkowych w aplikacji/usłudze trwało max. 5-10 sekund. Wtedy jestem w stanie odpalać je bardzo często i robić TDD. Jak integracyjny będzie się wykonywał powiedzmy 3 sekundy, to dla mnie nie jest problem, ale to mało realne.

2
jarekr000000 napisał(a):

@anonimowy: dokładnie tyle samo. Jeśli jako możliwości masz na myśli ścieżki. Jeśli masz na myśli wszystkie inputy (np. dla Int) ... to żadne testowanie Ci tego łatwo nie zapewni.

Nieprawda. Istnieje calkiem spora dziedzina IT zajmujaca sie formalnymi metodami dowodzenia poprawnosci dzialania programow.

Osobisie dziele testy na 4 kolejne etapy:
unit -> property based -> modeling (TLA+) -> formal proof

Polecam zwlaszcza jezyki typu TLA+ do otestowania zlozonych systemow rozproszonych, albo skomplikowanych ppd wzgledem wielowatkowosci, wspolbieznosci. Pan Klepman ma fajne konferencyjne wystapienia na ten temat - do znalezienia na YT.

1 użytkowników online, w tym zalogowanych: 0, gości: 1