In Uberspace 7 - Episode 2 haben wir das Thema Tests angerissen: Nachdem Features definiert wurden sollte man anfangen, Tests zu schreiben und damit die Anforderungen an die Features genau definieren. Aber wie sieht so ein Test eigentlich aus? Beispiel: Jeder User bekommt mit seinem Account eine Mailbox, die er mit seinem SSH-Kennwort abrufen kann. Ein Test dafür würde folgendermaßen aussehen: Einen User auf dem Server anlegen Ein SSH-Passwort setzen Eine Mail an User schicken Der User loggt sich per IMAP ein User holt Mail 1 per IMAP ab (Es kann nur eine Mail da sein, der User ist ganz frisch angelegt und das Postfach war vor der Testmail leer) Wir überprüfen den Inhalt der Mail auf einen bestimmten String Profit!

Vielleicht fragt ihr euch, wie man so ein System denn überhaupt entwirft, was die einzelnen Phasen der Entwicklung sind und wie unsere Arbeitsweise so aussieht. Mit herzlichen Grüßen aus dem Bergwerk folgt hier ein kleiner Einblick in unsere tägliche Arbeit und den aktuellen Stand der Dinge. Die Phasen der Entwicklung … und was wir anders machen würden, wenn wir nochmal von vorne anfangen würden. Features definieren Im ersten Schritt haben wir uns Gedanken darüber gemacht, was ein Uberspace eigentlich ist: Was unsere User erwarten, was wir selbst erwarten und was wir davon zuverlässig liefern können.

Die Sache mit den ETAs Eines unserer Grundprinzipien ist: Wir geben keine ETAs. Features kommen, wenn sie fertig sind und nicht zu versprochenen Zeitpunkten. Wir sind der Meinung, dass es nicht gut sein kann, unter Zeitdruck an etwas zu arbeiten und sind fertig, wenn wir eben der Meinung sind, dass wir fertig sind; wenn wir soweit hinter unserer Arbeit stehen, dass wir sie vertreten können und gut finden. Wir haben kein Venture Capital und keine Abteilung im Rücken, die darauf pocht, neue Features schnellstmöglich und unpoliert auf den Markt zu werfen und profitabel zu machen.