Eine allgegenwärtige Domänensprache für alle Tests

Eine der größten Herausforderungen für Ingenieure ist es, funktionierende Software zu schreiben und gleichzeitig eine umfangreiche Dokumentation zu führen. Die meisten Ingenieure hassen es, Dokumentation zu schreiben, und nachdem sie die Dokumentation in einem Wiki veröffentlicht haben, stirbt sie einen einsamen Tod. Wir wollen uns um das Schreiben einer  Lebendige Dokumentation in einer Allgegenwärtige Sprache. Praktiken wie Domain Driven Design (DDD) und Behaviour Driven Development (BDD) können Ihnen dabei helfen, dies zu erreichen. Besonders wenn wir mit dem Schreiben von Code beginnen, ist es für die Qualität unserer Software sehr wichtig, mit Tests zu beginnen, die beschreiben, was Ihre Anwendung tut. Wir wollen Software mit Einfühlungsvermögen schreiben, Software, die für Gleichgesinnte verständlich ist.  Während Softwareentwickler beginnen, in ihrem Anwendungscode mehr die Sprache der Domäne (Geschäftssprache) zu verwenden, enthalten die meisten Tests immer noch viel Fachsprache.

Einheitstest

Als Softwareentwickler kennen wir das alle: Sie nehmen ein neues Projekt in die Hand und versuchen zunächst herauszufinden, was es tut. Sie beginnen herauszufinden, wie das Design funktioniert und schließlich wollen Sie wissen, was ein Stück Software wirklich tut. Also öffnen Sie den Unit-Test und finden etwas wie die folgenden Testcode-Funktionen: [code language="java"] public void testReservation() public void should_reserve() public void buildReservation() [/code] Es könnte noch schlimmer sein, ein kritischer Softwarefehler wurde gemeldet und Sie versuchen herauszufinden, woher der Fehler kommt. Tests wie der im Beispiel sagen Ihnen nicht, wie sich der Code verhalten sollte, er passt nicht zu der Sprache, in der der Fehler gemeldet wurde. Um herauszufinden, was schief gelaufen ist, müssen Sie die Sprache bzw. den Kontext wechseln und übersetzen, was sehr zeitaufwändig ist und Zeitverschwendung bedeutet. Was in dieser Situation geholfen hätte, ist, dass die Tests so geschrieben sind, dass sie Ihnen sagen, wie sich der Code in der Domänensprache verhalten sollte. Auf diese Weise haben das Modell, in dem der Fehler gemeldet wird, und die Tests und der Code die gleiche Sprache und das gleiche Modell.

Abnahmeprüfung

Das gleiche Beispiel gilt normalerweise für Akzeptanztests. In den meisten Fällen werden diese immer noch von den Testern durchgeführt, was meiner Meinung nach ein merkwürdiges Verhalten ist, denn die einzigen, die in der Lage sind, sie zu brechen, sind eigentlich die Softwareentwickler. Wenn Sie das Glück haben, dass die Akzeptanztests den Entwicklern gehören, können Sie damit beginnen, durch diese Tests etwas Fachwissen zu sammeln. Dann öffnen Sie die Tests und finden nur das Folgende: [code language="text"] Szenario: Benutzer nach dem Einloggen auf die ursprünglich angeforderte Seite umleiten Angenommen, es existiert ein Benutzer "dave" mit dem Passwort "secret" und ich bin nicht eingeloggt Wenn ich zur Homepage navigiere, werde ich auf das Anmeldeformular umgeleitet[/code]das Anmeldeformular Wenn ich "Benutzername" mit "dave" und "Passwort" mit "geheim" eingebe und auf "Anmelden" drücke, sollte ich auf der Startseite sein. Das ist, wenn Softwareentwickler ein Tool außerhalb ihrer eigenen  Kontext, in diesem Fall normalerweise Cucumber. Wenn Sie dies lesen, erhalten Sie keine Informationen über das Verhalten des Systems, sondern nur über  wie das Verhalten implementiert wird. Das ist natürlich besser als keine Akzeptanztests, aber denken Sie an die Konsequenzen dieser Maßnahme. Normalerweise ändert sich das Verhalten eines Systems nicht, es gibt nur neues Verhalten, oder es wird Verhalten entfernt. DieImplementierungsdetails des Systems sind der einzige Faktor, der sich ändert. Jedes Mal, wenn dies geschieht, machen wir  Sie müssen nicht nur das System ändern, sondern auch die Funktionsdateien und den Testcode. Als Entwickler lernen wir, ein System mit geringer Kopplung zu erstellen, indem wir die Funktionen als Implementierung in  Gewürzgurke Dateien ist eine starke Kopplung, und das wollen wir wirklich nicht! Außerdem möchte ich als Softwareentwickler, dass die Dokumentation dem Modell und der Sprache der Domäne entspricht, was nicht die Implementierung sein sollte!

Domäne Sprache

Wirwollen Software und Tests erstellen, die der Sprache und dem Modell der Domäne entsprechen. Um dies zu erreichen, beginne ich in der Regel damit, den Teams, die ich berate, ein BDD-Format namens  Spezifikation durch Beispiel. Ich konzentriere mich darauf, dass die Teams die Sprache des Fachgebiets lernen und das Modell und die Sprache aufeinander abstimmen. Denken Sie daran, dass es hier um die Konversation geht und nicht um Werkzeuge. Ich möchte hier noch keine Tools einführen. Das Wichtigste ist das Lernen und Entdecken der Domäne. Nach einiger Zeit werde ich  andere Techniken einführen, wie z.B. Beispiel-Mapping, Event Storming und das OOPSI-Modell. In den folgenden Blog-Beiträgen werde ich näher auf die hier genannten Beispiele eingehen und verschiedene Tools besprechen, die Sie bei diesem Prozess unterstützen können.

Nehmen Sie am Meetup zu diesem Thema teil

Möchten Sie mehr über BDD (Example Mapping) und DDD (Event Storming) erfahren? Registrieren Sie sich für das Meetup am 11. Januar 2018 in Amsterdam Dem Meetup beitreten   Dieser Beitrag ist auch auf meinem persönlichen Blog baasie.com veröffentlicht.