Sie sind auf dem richtigen Weg zu schätzen wissen!
Also wie du schon gesagt hast When
ist ein Trigger, also lasst uns tiefer hineinschauen.
Gherkin wird für die verhaltensorientierte Entwicklung (BDD) verwendet, da Sie versuchen, das Verhalten zu simulieren.
Gegeben - Eingang - Voraussetzungen
Dies sind Dinge, die erwartet werden müssen, bevor die Aktion oder Trigger auftritt. Sie richten Ihre Tests für die Aktion ein, die ausgeführt wird.
Wenn - Auslöser - Aktion
Dies sind die Benutzer Verhalten, das das Ergebnis auslöst. Dies ist die B in BDD
Dann - Ausgabe - Ergebnis
Dies ist das Endergebnis, was soll der Benutzer erwarten, wenn das Verhalten abgeschlossen ist.
Wo Sie Stehen
So sind Sie in einer interessanten Situation, weil, wie Sie wies darauf hin, kein Verhalten. So ist der schwierige Teil, während ein Given-When-Then-Format ist schön, es ist völlig gültig, um eine Gegebenheit-Dann oder ein Wann-Dann-Format auch in Fällen, in denen es keine solide Benutzerverhalten. Also in diesem Fall:
Given it is 1 business day after the date state was changed to x
und
When it is 1 business day after the date state was changed to x
Sind beide gleich als gültig.
In Bezug auf Ihren zweiten Codeblock ist die Frage, die Sie sich stellen müssen, the email notification process triggered
ein Trigger oder ein Ergebnis? Persönlich würde ich sagen, dass es ein Ergebnis der Eingaben ist.Wenn Sie Sie nicht denken, müssen sie dann denke ich, Sie Ihren Test wie folgt schreiben sollte:
Given there is a user of type T
And the state is S
And it is 1 business day after the date state was changed to x
Then the email notification process should have triggered
And send an email notification to all users of type T with xxx content.
Bonus - Ihren Test Wort und Implementierungssprache
nicht vermeiden, dass Sie gefragt, aber es ist eigentlich ein Weg, um Ihre Tests Formulierung zu verbessern. Sie möchten Ihren Test von der eigentlichen Implementierung entkoppeln. Vermeiden Sie Wörter wie Senden, Klicken oder Tippen und konzentrieren Sie sich auf das Verhalten und das Ergebnis. Ich Ihren Test nehmen würde es so umformulieren:
Given there is a user of type T
And the state is S
And it is 1 business day after the date state was changed to x
Then all users of type T should be notified of xxx
ich die E-Mail-Benachrichtigung Schritt entfernt, weil das aus dem letzten Schritt geschlossen werden. Ich habe auch den letzten Schritt von der Implementierungssprache abgekoppelt. Wichtig ist hier nicht, dass der Nutzer eine E-Mail erhält, sondern dass er über den Inhalt informiert wird. Ihre Given
Schritte sollten meiner Meinung nach auch abhängig von Ihrer Geschäftslogik geändert werden, da sie momentan sehr an Ihre Implementierung gekoppelt sind.
Was für eine erstaunliche und aufschlussreiche Antwort. . Ich denke, die Given-Then-Ansatz macht voll und ganz Sinn. Das war mein erster Gedanke, aber ich wollte sicherstellen, dass ich dem Konstrukt treu blieb. – user9445
Die Bonussektion ist eine große Hilfe. Ist es fair zu sagen, dass das Ziel, Verhalten von der Umsetzung zu entkoppeln? In Ihrem Code-Snippet wird der Benutzer "über das xxx" (Verhalten) informiert, aber der Teil, der fehlt (per E-Mail). Als jemand, der das Annahmekriterium schreibt, scheint es mir, dass Voraussetzung, Aktion und Ergebnis erforderlich ist, aber der Teil (per E-Mail) ist auch erforderlich. Da gibt es einen Benutzer vom Typ T und der Staat ist S und es ist 1 Werktag nach dem Datum Zustand x Dann wird alle Benutzer vom Typ T von XXX _by email_ – user9445
Am Ende mitgeteilt wurde geändert sollten An dem Tag, an dem Sie das tun müssen, was zu Ihren ACs passt, versuche ich in meinen Teams in der Regel so viel wie möglich zu entkoppeln, denn wenn sich die Implementierung ändert, ändern sich die ACs nicht. Wenn sich beispielsweise die Implementierung von E-Mail in Text ändert, hat sich die AC nicht geändert, der Benutzer wird dennoch benachrichtigt. Was sich änderte war, wie sie benachrichtigt wurden. –