Es ist wieder Zeit für eine Lern-Kaffeepause, heute zum Thema Softwaretest! Die fünf Minuten reichen diesmal nur für einen Kurzüberblick, um die verlinkten Artikel alle zu lesen, nehmt euch etwas mehr Zeit.
- Testet ihr composer Packages oder Projekte mit Travis CI? Nehmt die Abhängigkeiten mit in die Build Matrix auf! Mit
composer update --prefer-lowestwerden statt möglichst aktueller Versionen, möglichst alte Versionen installiert. Wenn nicht beides funktioniert, stimmen die Version Constraints offenbar nicht. Wie das geht: Test lowest, current, and highest possible on Travis - Test Doubles, die eine externe API simulieren, sollten regelmäßig selbst getestet werden, ob die Rückgabe noch das selbe Format hat wie die tatsächliche API. So können Änderungen an der API rechtzeitig erkannt werden. Martin Fowler nennt das Integration Contract Test
- Apropos Test Doubles. Anstatt Mocking Frameworks zu verwenden, ist es häufig sinnvoller, mit Fakes zu arbeiten, also Dummy-Implementierungen der zu doublenden Interfaces, mit eigener Logik aber ohne externe Abhängigkeiten. Das kann z.B. ein “InMemoryMailer” sein, der Mails nicht versendet sondern intern speichert und für Tests Methoden zur Inspektion bereitstellt, wie “sentEmails()” oder “hasEmailBeenSentTo($recipient)”. Mehr dazu: Writing Your Own Test Doubles
- Giorgio Sironi erklärt in Hello world in a production environment eine Daseinsberechtigung von “Hello World” Programmen, als simpler Test für Entwicklungs- und Produktionsumgebungen. Zum Beispiel: Hello World Unit Test, Ping API, Hello World Microservice.
Die Idee ist, dass im eigentlichen “Hello World” Code nahezu garantiert keine Bugs sind. Er eignet sich also hervorragend als Test für Boilerplate Code und Umgebung.
