Let’s review "reversible raincoat tests."
Sometimes, we build systems in which a downstream collaborator must interface with an upstream one. The two apps are by separate teams, on separate servers, developed at separate times, and still both in development.
A reversible raincoat test is a script with two sides. Think in terms of a literal script, like in a play.
"Mike: hi mom. Mom: hi son. Mike: is today tuesday? Mom: no, doofus, it’s thursday. Mom: gotta go, basement is flooding. Mike: okay, bye." the idea is a) use these scripts to facilitate the interface discussion & design. B) run those scripts in both directions. That is, we need to test that mike does his part correctly, AND we need to test that mom does her part correctly.
So a reversible raincoat test is always a shared resource between two teams. The great value is a) the communication, and b) the ready ability to sanity-check. There is a real knack to supplying the right amount of detail for these, and you’ll have to practice.
One key, tho: avoid stuff like raw html caps. They tend to be far too brittle. And timestamps are also a no-no for the most part.
A key value: make them graspable easily by humans, a la gherkin or other comparable DSL.
If I can’t run my side of the script, there’s no point in releasing it outside my team, and the same goes for the other team and theirs. It really does save a lot of time to not do "false starts" on integration tests.