[M.....4]

Mirki, przerabiam sobie kurs C# na Pluralsight ( C# Fundamentals 7/3 ), mamy takie zadanko, aby zrobić test jednostkowy, sprawdzający, czy ocena do klasy Book może zostać dodana, jak poniżej.

public void AddGrade(double grade)
{
if (grade <= 100 && grade >= 0)
{
grades.Add(grade);
}
else { Console.WriteLine("Invalid Value."); }

Wiem, że to działa prawidłowo i nie dodamy np. oceny 105, ale nie wiem jak do tego napisać test jednostkowy. Próbowałem na zasadzie, Asserts.Equal(105, Book.grades[0]), no ale to nie pyka, bo przecież Book.grades[0] nie będzie istnieć, jeżeli spróbuje temu nadać wartość powyżej 100.

Mam nadzieję, że udało mi się to dobrze wytłumaczyć. Z godzinę starałem się to zrobić lub znaleźć jakieś wyjaśnienie w internecie, ale nic z tego. Pomocy (╯︵╰,)

#programowanie #csharp

[a.....e]

@Michian484: 1. Magiczne liczby
2. Powinieneś mieć przypadki "should not add grade" i wymagać dla <0, >100 zeby bylo empty

Edit: Upraszczając - w tym scenariuszu nie masz sprawdzić grades[0] tylko grades.isEmpty() czy tam size/length == 0

[UberRam]

@Michian484: mozesz np. utworzyc obiekt grades w swoim tescie z oczekiwanym stanem, a nastepnie zbadac przy pomocy asercji czy tak samo wyglada jak aktualny obiekt grades po wywolaniu AddGrade (z dodanym elementem okreslonej wartosci)

[MQs]

@Michian484: Jeżeli masz zrobić test jednostkowy tak napisanej metody (bez jej refaktoryzacji) to szukaj innego kursu.
Testem jednostkowym nie sprawdzasz bezpośrednio efektów ubocznych (zmian w otoczeniu programu - pliki, bazy danych, zdalne serwisy czy jak tutaj konsola). Musisz je oddzielić od aplikacji przez port (interfejs) i adaptery (implementacje) - przy testowaniu będą co najmniej dwa adaptery: jeden to prawdziwa konsola, drugi to mock zapisujący wynik do pamięci, który można odczytać

[M.....4]

@aloucie: @UberRam

Dzięki za odpowiedzi.

Dzięki Waszym propozycjom, napisałem to w

[M.....4]

Ok, właśnie zauważyłem sugestię z VS, która jest dużo lepsza niż moje rozwiązanie: Assert.Empty(book.grades); .

[UberRam]

@Michian484: generalnie testuje sie kontrakty jakie dana jednostka testowana obiecuje spelniac, a nie implementacje tego jak to robi (dlatego zadne wewnetrzne ify nie powinny miec wplywu na kod testu). Implementacja moze sie zmieniac, a Twoje testy testujace kontrakt powinny dzialac niezaleznie od implementacji. Scenariusze testowe pisane sa wedlug konktraktu, np. zeby pokryc wartosci brzegowe (a nie to ze sa spelnione w implementacji w postaci ifow).