An diesem Team-Tag geht es rund ums Thema “Unit-Testing” - wofür ist das gut, was sollte man dazu wissen, und wie macht man es ganz praktisch. Diese Seite dient euch als Orientierungshilfe durch den Tag.
Die Laptops, die von der TH Köln gestellt werden, sind bereits entsprechend vorbereitet. Für alle anderen Laptops spielt bitte folgende Software auf:
Das machen wir heute.
Von | Bis | Thema |
---|---|---|
9:00 | 9:15 | Intro und Motivation |
9:15 | 10:15 | Unit Test Essentials |
10:15 | 10:30 | PAUSE |
10:30 | 11:30 | Refactoring |
11:30 | 12:00 | TDD und neues Feature |
12:00 | 12:45 | Mittagspause |
12:45 | 13:15 | TDD und neues Feature (Forts.) |
13:15 | 14:45 | Test-Typen, Mocks und Fakes |
14:45 | 15:00 | PAUSE |
15:00 | 17:00 | Praktische Anwendung |
17:00 | 17:15 | Kurze Abschluss-Reflektion |
17:15 | … | … der entspannte Teil :-) … |
Manager können nicht entlassen werden. Das ist ein Bug. (Versucht es. Es geht nicht.) Wir ändern das so, dass die Mitarbeiter nach der Entlassung an den nächsthöherer Manager berichten. Oder an niemanden, wenn ein Director entlassen wird.
Versucht mal, einen Mitarbeiter zu sich selbst zu versetzen - oder zu jemandem aus dem Kreis seiner Untergebenen. Es gibt dann eine Endlosschleife. Löst das Problem, indem ihr die Versetzung in so einem Fall verhindert.
Es gibt einige Typen, die sehr unelegant als char
(der PayGrade) oder string
(die Email) implementiert sind.
Was ist z.B., wenn der PayGrade in einer Eingabe nicht zwischen A und E liegt? Wir wollen das ändern, indem wir
dedizierte Typen für diese Werte erstellen (sogenannte Domain Primitives, wie Address
). Das sind Value Objects - immutable und ohne Identität,
also gleich wenn alle Attribute gleich sind.
Konzentriert euch mal auf einen der beiden Fälle und erstellt erst einmal Unit Tests für Employee
, damit ihr dann sicher sein könnt, dass ihr
durch das Refactoring nichts kaputt macht. Eine Bedingung ist z.B., dass darf der Vorgesetzte nicht weniger verdienen darf als sein Mitarbeiter.
(PS: Die Methode Employee.SetNewSuperior(...)
enthält einen Bug. Findet ihn und behebt ihn in dem Zuge mit.)
Lasst euch ein neues Feature einfallen, das ihr gerne in der Anwendung hätten möchtet. Schreibt dazu einen Test, der das neue Feature beschreibt. Implementiert dann das Feature. Beispiele:
Schreibt einen Fake für den WebService, der die Telefondaten aus dem Internet holt, wenn die Telefonnummer nicht gesetzt ist. Außerdem könnt ihr euch einen Weg überlegen, wie man im Test die InMemoryDB benutzen kann.
Damit schreibt dann bitte Integrationstests für die REST-Endpoints, oder zumindest für einen Teil davon.
Bitte nehmt euch kurz Zeit, um eure Erfahrungen und Eindrücke des Tages zu sammeln. Ihr könnt das hier eintragen: https://easyretro.io/publicboard/AOHBNOBYPnOhH7SiyzsQEVKivTf2/70ae1f4b-160c-4551-8969-6bc0846d236e