← Graph

Should fake implementations live with production code?

question 5 connections

Audience asks whether reusable test-only objects (fake dice, fake current-time) should live with production files so they can be shared across tests. Rodzik never keeps them with production code — he would rather duplicate a rarely-changing fake than risk test code leaking into production. Suggests helpers or factories if deduplication is needed. A follow-up audience comment recommends running the same behavior suite against both real and fake implementations (an approach covered in 99 Bottles and POODR by Sandi Metz), ideally with the team that owns the real class also owning the fake. Another attendee suggests RBS to keep signatures aligned automatically.

answer_summary
Rodzik keeps fakes out of production code even at the cost of duplication. Audience adds: run the same suit of behavior tests against both fake and real, have the real-class team own the fake, and/or use RBS to keep signatures in sync.
question Should fake implementations live with production code?
about
Fake Object concept
Asks where fake implementations should physically reside.
question Should fake implementations live with production code?
about
Referenced in the answer as a source for the 'test both fake and real' approach.
question Should fake implementations live with production code?
about
Referenced in the answer as a source for the 'test both fake and real' approach.
question Should fake implementations live with production code?
about
RBS tool
Follow-up audience suggestion to use RBS to keep real and fake signatures aligned.
question Should fake implementations live with production code?
asked_at
Audience question during Q&A.

Provenance

Read by
4 extractions