Wytłuacznie testów jednostowkych

Cześc może ktoś mi wyłumaczyć jak napisać do takiej przykładowej metody testy jednostkowe ?

public String  przykladowaMetoda(Car car, int numbersOfDors, boolean  isNew){
	if(isNew && numbersOfDors == 4){
		if(Car.model.equles("AUDI")){
			setValue(true);
		}else
			setValue(false);
	}
	return "STRING";
}

setValue() tylko ustawia mi wartosć na true/fasle np, zarejestrowny/niezarejestrowany to tylko taki przykald na szybko

TakMaszRacje napisał(a):

Cześc może ktoś mi wyłumaczyć jak napisać do takiej przykładowej metody testy jednostkowe ?

[...]

Musiałbyś pokazać co robi setValue().

PS: numbersOfDors = 4 tu nie powinno być == albo !=?

TakMaszRacje napisał(a):

setValue() tylko ustawia mi wartosć na true/fasle np, zarejestrowny/niezarejestrowany to tylko taki przykald na szybko

No ale żeby napisać dobry unit test trzeba wiedzieć jak tak ustawiania wartośc jest potem używana, na tym polega cały sekret; także musisz coś więcej kodu pokazać/wymyślić.

Co robisz potem z tą value? Wystawiasz potem getterem, czy co z tym robisz w tej klasie?

Zacznijmy od tego ze tą metodę należałoby przepisać:

public Optional<Boolean> przykladowaMetoda(Car car, int numbersOfDors, boolean  isNew){
	if(isNew && numbersOfDors == 4){
		if(Car.model.equles("AUDI")){
			return Optional.of(true);
		}else{
			return Optional.of(false);
        }
    }
    return Optional.empty();
}

public String przykladowaMetoda2(Car car, int numbersOfDors, boolean  isNew){
    przykladowaMetoda(car, numbersOfDors, isNew)
      .ifPresent(v->setValue(v));
    return "STRING";
}

I cyk, nagle mamy metodę którą można dość prosto przetestować bo zwraca wartość.

Nie lepiej to zamknąć w jakimś obiekcie zamiast robić tego typu utilsowe metody?

class Car {
    
    private String model;

    private int numberOfDoors;

    private boolean isNew;

    public String przykladowaMetoda() {
        if (isNew && 4 == numberOfDoors) {
            setValue("AUDI".equals(model))
        }
        return "STRING";
    }
}

class CarTest {
    
    @Test
    void dummyTest() {
        // given
        var car = Car.builder()
        .model("AUDI").numberOfDoors(4).isNew(true).build();

        // when
        var result = car.przykladowaMetoda();

        // then
        assertThat(result).isEqualTo(expectedResult);
        assertThat(car.getValue()).isTrue();
    }
}

Najlepiej Ci to wytłumaczy Beck Kent który zapoczątkował idee TDD w książce "TDD. Sztuka tworzenia dobrego kodu"

Dopisywanie testow do metody :(((((((((

Co bedzie z tymi testami jak ta metoda zmieni sygnature albo zostanie zinlinowana?

1. Napisz co ta klasa/komponent/modul/jednostka ma robic biznesowo
2. Dla kazdego punktu napisz test
3. Dopisz testy na jakies cornery
4. Profit

Charles_Ray napisał(a):

Dopisywanie testow do metody :(((((((((

Co bedzie z tymi testami jak ta metoda zmieni sygnature albo zostanie zinlinowana?

1. Napisz co ta klasa/komponent/modul/jednostka ma robic biznesowo
2. Dla kazdego punktu napisz test
3. Dopisz testy na jakies cornery
4. Profit

5. Nie testuj metod tylko zachowania.

a jakbym chcial przetestować tyllko argumnety ktore metoda przyjmuje i wtedy dzialanie warunkow ?

TakMaszRacje napisał(a):

a jakbym chcial przetestować tyllko argumnety ktore metoda przyjmuje i wtedy dzialanie warunkow ?

Ale te argumenty przekazujesz po coś. Ich wartość wpływa na inne wartości, albo to co funkcja zwraca albo ustawienie wewnętrznego stanu obiektu.

I pod to się pisze testy. W ogóle sama idea "testowania funkcji" jest bez sensu. Powinieneś tak napisać testy, żebyś potem mógł zrefaktorować funkcję lub ją całkiem usunąć, a testy nie powinny failować (zakładając że nie zmieniłeś zachowania).

Może pokaż całą klasę albo moduł do którego chcesz napisać te testy? Chyba że może nie chcesz nic testować, tylko chcesz się nauczyć pisać testy po prostu?

@TakMaszRacje musisz odwrocic myslenie i najpierw napisac przypadki testowe, a potem implementacje. Ew. jak jest za pozno, to i tak najpierw pomyslec nad przypadkami bez patrzenia w kod - potem ew. dopisac kilka testow na corner casy.

Co w momencie, gdy implementacja jest bledna albo brakuje jakiegos warunku - tez bedziesz dopisywal testy? Ogon nie moze krecic psem. Do czego moze doprowadzic takie podejscie mozesz posluchac tu: (tam jest nawet przyklad z asercja na kazda linijke :D)