If the backends are slow or flaky, an impersonator may help some aspects of immediate feedback to the developers – but the underlying problem must be addressed! More effort is expended working around crappy backend services than what it takes to fix them.

Using an impersonator during a showcase feels like duping the sponsor. You are not showing working software. You are showing the working facade over some smoke and mirrors.

BESIDES, if the development team has to deal with the crappy backends, then it should be HIGHLY VISIBLE to the sponsor. When the showcase is a shambles and maybe the sponsor will have enough impetus to do something about it for the good of all.

In terms of feedback, the danger is the impersonator is not doing a good job and the feedback contains false positives. Martin relayed the technique Josh Price mentioned about to have the SelfInitializingFake check against thru to the real service within selected contexts.

Mocks, stubs and fakes are useful at progressive points in the build pipeline to substitute for the real things they are masquerading. But, just like you wouldn’t use a mock in a showcase environment (let along production), nor should you use a fake for showcases, nor rely on them as proofs in integration or functional tests.

Remember, the automated build, test and deploy facilities are there for us to show why the candidate build should NOT be released to production. Tests passing in a non-representative context do not reach that goal.

Likewise, showcases are there for us to give the customer a view of the software that they can release to production NOW. Demonstrations in a non-representative context do not reach that goal.

As with any “pattern”, use with caution, and appropriately.