Z dyskusji o testach

 Na uczelnianym Discordzie wynikła dyskusja o TDD i o różnych praktykach z tym związanych, wklejam poniżej swoją wypowiedź z krótkim przykładem jak w tym momencie rozumiem testowanie.

załóżmy prosty interfejs:

    public interface Calculator {
        int add(int a, int b);
    }

implementowany przez prostą klasę:

    public class SimpleCalculatorImpl implements Calculator {
        @Override
        public int add(int a, int b) {
            return a + b;
        }
    }


oraz napiszmy bardziej zaawansowaną implementację:

    public class AdvancedCalculatorImpl implements Calculator {
        private final CalculatorService calculatorService;
        public AdvancedCalculatorImpl(CalculatorService calculatorService) {
            this.calculatorService = calculatorService;
        }

        @Override
        public int add(int a, int b) {
            return calculatorService.add(a, b);
        }
    }

    public class CalculatorService {

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

Jak to przetestować? Generalnie wszystkie klasy implementujące Calculator mają tylko jedno zadanie biznesowe – przyjąć dwie zmienne w metodzie add i zwrócić odpowiedni wynik. Więc to są kluczowe testy dla TDD i dla utrzymania projektu, które pozwolą na pisanie zupełnie nowych implementacji w przyszłości.

Oprócz tego każda klasa ma swoje własne szczegóły, które można testować, np. AdvancedCalculatorImpl bazuje na właściwym działaniu CalculatorService, więc testy powinny zabezpieczać ją przed "zepsuciem" lub niepoprawnym działaniem tej zależności.

Z perspektywy teoretycznej (bo nie mam doświadczenia w open source) to testy każdej z tych klas są i mogą być pożyteczne, bo przecież ulepszenie projektu możesz nastąpić przez napisanie nowej implementacji Calculatora, ale może wystarczy tylko zoptymalizować już istniejącą lub jej zależność.

Powyższa wypowiedź jest odpowiedzią na informację, że w projektach open source często testy nie są częścią repo lub są ukrywane, aby nie blokować możliwości rozbudowy projektu przez innych, i by nie sugerować że implementacja pierwotna jest jedyna możliwa.