Related to (or a sub-part/refinement of) “contract testing”, that I periodically highlight:

Produced by OmniGraffle 7.8 2018-07-13 18:27:42 +0000Canvas 1Layer 1Programatictests ofservicesUsages ofwireservices(prod code)ProgramaticmockwireservicesReal wireservices(prod code)Programatictests ofservicesUsages ofwireservices(prod code)ProgramaticmockwireservicesReal wireservices(prod code)Programatictests ofservicesUsages ofwireservices(prod code)Real wireservices(prod code)Programatictests ofservicesUsages ofwireservices(prod code)ProgramaticmockwireservicesReal wireservices(prod code)Two tiers ofour productionstack (one viaSOA or µServicesor BFFs, etc)TechnologyCompatibilityKit (TCK) -Not soconventionalin 2018✅devs run this before commit/push✅Jenkins runs thisprior tothe ‘integrate’moment per commit or pull request✅Jenkins runs this againfor CIafter integrate(merge) per commit or pull-request✅Wire mocks ALSO represent enough of thedown-stack dependency for the devs, QAsand build-savvy power users to be able todo exploratory testing.👈👈Our regular 2018 dev/test automation excellenceSystemUnder Test(SUT)Depend-enciesWe prefer tofunctionally*testthis in isolationSpecificallyNOTat the sametime as testing these👈👈Programaticmockwireservices👈A reminder about testing best practice generally* load, perf, full-stack tests are different✅tests are adaptive between mocks and reals forknown QA set of data (subject to its own bestpractices, including curation and resetability)

Wire mocks are officially “service virtualization” (SV) of course. The TCK idea is a specific usage of them, originally to allow alternate implementations. Vendors making services (on the internet or installable on-prem or cloud) should make a TCK, too. They may want to include a “no reverse-engineering” clause for licensees of the TCK so they don’t make it too easy for their competitors. Lawsuits of note:

Incidentally, on-prem is short for “on premises”, and not at all the same as “on premise”.