Trudny / egzaminacyjny · lekcja 10

Zadanie kontrolne — klasa z logiką i pełny zestaw testów jednostkowych

To podsumowanie całego działu: napiszesz od podstaw klasę z logiką biznesową i KOMPLETNY zestaw testów jednostkowych — dokładnie w takim stylu, w jakim może pojawić się zadanie na egzaminie praktycznym INF.04. Zadanie sprawdza, czy potrafisz samodzielnie zapro...

Zacznij tutaj

Po co się tego uczymy?

To podsumowanie całego działu: napiszesz od podstaw klasę z logiką biznesową i KOMPLETNY zestaw testów jednostkowych — dokładnie w takim stylu, w jakim może pojawić się zadanie na egzaminie praktycznym INF.04. Zadanie sprawdza, czy potrafisz samodzielnie zaprojektować przypadki testowe (typowe, brzegowe, błędne), a nie tylko odtworzyć gotowy przykład z lekcji.

Wprowadzenie

Teoria

Specyfikacja zadania. Zaprojektuj i zaimplementuj klasę RezerwacjaSali obsługującą rezerwacje sal konferencyjnych w firmie, wraz z KOMPLETNYM zestawem testów jednostkowych (MSTest lub xUnit — do wyboru). Wymagania funkcjonalne:

  • Metoda CzyDostepna(DateTime poczatek, DateTime koniec, List<Rezerwacja> istniejaceRezerwacje) zwracająca bool — sala jest DOSTĘPNA, jeśli nowy termin NIE nakłada się (w żadnym punkcie) z żadną z istniejących rezerwacji.
  • Metoda DodajRezerwacje(DateTime poczatek, DateTime koniec, string osoba) — dodaje nową rezerwację, ale RZUCA wyjątek InvalidOperationException, jeśli termin koliduje z istniejącą rezerwacją.
  • Walidacja: koniec musi być PÓŹNIEJSZY niż poczatek (w przeciwnym razie ArgumentException); rezerwacja nie może trwać dłużej niż 8 godzin.
  • Metoda LiczbaRezerwacjiWDniu(DateTime dzien) zwracająca liczbę rezerwacji przypadających na wskazany dzień.

Wymagania dotyczące testów (to jest właściwe zadanie kontrolne — ocena dotyczy GŁÓWNIE jakości i kompletności testów, nie samej implementacji):

  1. Zastosuj zasadę AAA (Arrange-Act-Assert) w KAŻDYM teście.
  2. Pokryj testami przypadek TYPOWY (poprawna rezerwacja, brak kolizji).
  3. Pokryj testami przypadki BRZEGOWE: rezerwacja kończąca się DOKŁADNIE w momencie rozpoczęcia innej (czy to kolizja?), rezerwacja trwająca dokładnie 8 godzin (graniczna, dozwolona) i 8 godzin + 1 minuta (niedozwolona).
  4. Pokryj testami przypadki BŁĘDNE: koniec wcześniejszy niż poczatek, próba dodania rezerwacji kolidującej z istniejącą.
  5. Nazwij testy zgodnie z konwencją Metoda_Scenariusz_OczekiwanyWynik (lekcja 2).
  6. Napisz krótką dokumentację (komentarz XML doc, lekcja 8) dla metody CzyDostepna.

Zobacz zależności

Schemat

RezerwacjaSali
 ├── CzyDostepna(poczatek, koniec, istniejące) : bool
 ├── DodajRezerwacje(poczatek, koniec, osoba)   : rzuca InvalidOperationException przy kolizji
 └── LiczbaRezerwacjiWDniu(dzien)                : int

PRZYPADKI DO PRZETESTOWANIA:
  ✓ typowy: 10:00-11:00 vs istniejąca 14:00-15:00 → dostępna
  ⚠ brzegowy: 10:00-11:00 vs istniejąca 11:00-12:00 → dostępna (styk, nie nakładanie)
  ⚠ brzegowy: rezerwacja dokładnie 8h → dozwolona
  ✗ błędny: koniec przed początkiem → ArgumentException
  ✗ błędny: 9:00-18:01 (8h 1min) → ArgumentException
  ✗ błędny: DodajRezerwacje z kolizją → InvalidOperationException

Połącz z praktyką

Przykład z życia

Systemy rezerwacji sal konferencyjnych (Outlook, Google Calendar Rooms) codziennie rozwiązują dokładnie ten problem: sprawdzają, czy proponowany termin NIE nakłada się z żadną istniejącą rezerwacją, uwzględniając subtelne przypadki brzegowe — czy spotkanie kończące się dokładnie o 11:00 koliduje z innym zaczynającym się o 11:00 (zwykle NIE — to "styk", nie nakładanie). Właśnie takie subtelności są source większości błędów w prawdziwych systemach rezerwacji i dlatego wymagają starannie zaprojektowanych testów.