Warum denken Sie, dass BDD und Integrationstests unterschiedlich sind?
BDD bedeutet nur, dass Sie Ihr Design durch das gewünschte Verhalten steuern, das normalerweise durch eine Reihe von Abnahmetests ausgedrückt wird.
Diese Tests können "Integrationstests" sein, die viele [micro] -Dienste umfassen, oder sie können Tests sein, die das gewünschte Verhalten eines einzelnen Dienstes oder einer einzelnen Klasse in diesem Dienst angeben. Idealerweise wird es eine Mischung von Tests auf allen diesen Ebenen geben. Wichtig ist, dass Sie das gewünschte Verhalten angeben und damit die Entwicklung steuern.
Wie Ihr System implementiert ist, ist in gewisser Hinsicht irrelevant, solange es das erwartete Verhalten zeigt. Für die High-Level-Tests, die das System als Black-Box behandeln, gilt dies, und je niedriger Sie gehen und je näher Sie dem eigentlichen Code kommen, desto weniger wird dies wahr (da Sie die Implementierung zu diesem Zeitpunkt tatsächlich testen).
Ich würde mich also auf das von den neuen Funktionen erwartete Verhalten konzentrieren und zuerst die Spezifikationen für diese Abnahmetests schreiben, dann Ihre Dienste implementieren, um das erforderliche Verhalten zu erfüllen, unter Berücksichtigung pragmatischer, niedrigerer Tests Je niedriger die Tests, desto wahrscheinlicher sind sie fragil und müssen geändert werden, wenn Sie Ihre Implementierung ändern.
EDIT
auf Ihre Frage bearbeiten Basierend.
Ich bin nicht damit einverstanden, dass BDD-Tests nur die Geschäftslogik testen sollten. Tatsächlich ist es üblich, dass BDD-Tests sich mehr darauf konzentrieren, das System als Ganzes zu testen, wobei alle Teile zusammen integriert sind. Allerdings ist BDD nur eine Art zu testen, indem das gewünschte Verhalten spezifiziert wird, und kann auf jede Ebene der Anwendung angewendet werden. Sie können eine einzelne Klasse testen, indem Sie das Verhalten mithilfe der Gherkin-Syntax angeben, und wir tun dies manchmal. Wir spezifizieren auch das erwartete Verhalten des gesamten Systems mit Gherkin und das erwartete Verhalten unserer Dienstleistungen individuell. Diese Tests werden natürlich ein etwas anderes Format haben, abhängig von der Ebene, auf die wir zielen.
Für die Systemtests könnten wir Spezifikation wie dieses:
Scenario: user can perform action A
Given I am a user with access to some feature A
And feature A is enabled for the user
When I call perform action A with parameters 'Bob' and 'John'
Then A 'BobJohn' is created
And notifications are sent to the current user
für einzelne Dienste könnten wir Tests haben wie
Scenario: create messages are handled correctly
Given the service is set up
When a message arrives to create a 'BobJohn'
Then a new entry is added to the database with the key 'BobJohn'
And an outgoing notification message for 'BobJohn' is created
Für einzelne Klassen könnten wir haben Tests wie
Scenario: Notifier class should send notifications via all users preferred means
Given the current user wants notification by Twitter
And the current user who wants notification by email
When I send the notification 'BobJohn' to the current user
Then the twitter notifier should be invoked with 'BobJohn'
And the email notifier should be invoked with 'BobJohn'
Dies sind alle BDD-Style-Tests, aber sie testen verschiedene Aspekte des Systems tem.
Der Autor von BDD in Aktion denkt, dass sie kompatibel sind: http://www.slideshare.net/wakaleo/bdddriven-microservices – ngm
Vielen Dank für die Kenntnisnahme. Ich habe gerade einige Artikel gelesen, die von JF Smart geschrieben wurden, wir teilen die gleichen Ansichten zu dieser Frage. Er sagt, dass sie in verschiedenen Phasen der Entwicklungen kompatibel sind. Wenn die Lösungsarchitektur es möglich macht (ich hoffe, dass eine Abstiegsarchitektur dies ermöglicht), passt BDD optimal für geschäftliche Akzeptanztests. Sobald die Akzeptanztests in Ordnung sind, sollen Integrationstests die Lösung gegen eine Zielinfrastruktur testen. Trennung von Bedenken. Er behauptet, es sei Zeitverschwendung, die Standardwerte für die Akzeptanz von Entwicklern aus Integrationstests zurückzudrängen. Kompatibel, aber nicht gleich. –