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.