tusharpokle

I've written, and seen plenty of Integration tests as described by Gus - to test the entire vertical slice of software in a realistic environment without stubs, mocks or fakes as much as possible. I find those very useful because programmers tend to surround themselves with stubs, mocks and fakes forgetting about the real world only to have it turn up in the production environment.

What I've never seen is anyone writing integrated tests attempting to test the minute interactions of every component with every neighbour. Doing so would be madness as you've pointed out.

1 reply

jbrains

"I find those very useful because programmers tend to surround themselves with stubs, mocks and fakes forgetting about the real world only to have it turn up in the production environment." I wouldn't like to use integrated tests for that purpose; I'd use them for others, as I've written elsewhere. If a programmer forgets about the real world, then he needs to raise his discipline, and a compensating practice like integrated tests doesn't encourage him to raise his discipline the way I'd like. A trapeze artist doesn't use a safety net as an excuse to avoid learning how not to fall.

"What I've never seen is anyone writing integrated tests attempting to test the minute interactions of every component with every neighbour. Doing so would be madness as you've pointed out." Right. They do, however, use integrated tests to try to uncover or mask randomly distributes integration errors throughout the system, and the more integration errors they make, the more integrated tests they want to write. That's madness, too, but they seem to think nothing of it. I want them to think something of it.