Git ignores the build directory of the Spring-Consumer

[demos/example-siren] / README.md

diff --git a/README.md b/README.md
index 9ad63b5..afe9eae 100644 (file)
--- a/README.md
+++ b/README.md
@@ -2,7 +2,7 @@
 Example project using [Siren](https://github.com/kevinswiber/siren) for hypermedia entities and testing with Pact.
 
 This project has two sub-projects, a provider springboot project which is using `spring-hateoas-siren` to provide Siren
-responses and a Javascript consumer project `ketting` to parse and navigate the Siren responses. 
+responses and a Javascript consumer project using `ketting` to parse and navigate the Siren responses. 
 
 ## Provider Project
 
@@ -108,12 +108,10 @@ The problem with using normal Pact tests to test this scenario is that Siren res
 actions. The URLs when running the consumer test will be different than those when verifying the provider. This will 
 result in a verification failure.
 
-To get round this problem, we use the `url` matcher function from the consumer Pact DSL. This function takes a base URL,
-and a list of path fragments. The path fragments can be either plain strings or regular expressions. It then constructs
-the actual URL to use in the consumer test, and a regular expression matcher that can match the URLs in the provider
-verification test.
-
-To show this working, the consumer Pact test has the mock server running on port 9000, while the provider will be running on port 8080.
+To get round this problem, we use the `url` matcher function from the consumer Pact DSL. This function takes a list of 
+path fragments. The path fragments can be either plain strings or regular expressions. It then constructs
+the actual URL to use in the consumer test using the mock servers base URL, and a regular expression matcher that can 
+match the URLs in the provider verification test.
 
 ### Dealing with hypermedia formats like Siren actions
 
@@ -158,12 +156,12 @@ For example, in the consumer test we can specify:
   {
     "name": "update",
     "method": "PUT",
-    "href": url("http://localhost:9000", ["orders", regex("\\d+", "1234")])
+    "href": url(["orders", regex("\\d+", "1234")])
   },
   {
     "name": "delete",
     "method": "DELETE",
-    "href": url("http://localhost:9000", ["orders", regex("\\d+", "1234")])
+    "href": url(["orders", regex("\\d+", "1234")])
   }
 )
 ```
@@ -263,3 +261,25 @@ See https://docs.gradle.org/6.6.1/userguide/command_line_interface.html#sec:comm
 BUILD FAILED in 4s
 8 actionable tasks: 6 executed, 2 up-to-date
 ```
+
+# Notizen
+
+* Die Anordnung der Kontrakte ist je nach Implementierung unterschiedlich.
+* __Dies ist kein Fehler!__
+  * Der JavaScript-Consumer erweckt den Anschein, dass die Reihenfolge
+    der Aufrufe im Kontrakt erhalten bleibt, so dass beim Testen des
+    Providers gegen den Kontrakt automatisch der benötigte Zustand
+    existiert.
+  * Dies ist aber _nicht_ so und soll so auch nicht sein.
+  * Der Provider ist in diesem Beispiel einfach so implementiert, dass er
+     gar keinen Zustand hält und nur das erwartete JSON für ausgedacht Werte
+     erzeugt.
+  * Ein Test mehrerer aufeinander folgenden Aufrufe, die sich selbst den
+     benötigten Zustand erzeugen (z.B. Erzeugen / Auflisten / Löschen) ist
+     nicht möglich und aus der Sicht von Pact auch nicht sinnvoll!
+  * Der Kotrakt soll nur sicherstellen, dass sich Consumer und Provider
+    verstehen.
+* Für den Vergleich, den Pact normalisieren mit:
+  ```
+  cat PATH_TO_PACT | jq '.interactions|=sort_by(.description)' > NORMALIZED
+  ```