Eric, a smart guy at work, said the following on an internal mailing list (emphasis his):
Developer tests (I avoid “unit tests†because “unit†means 13 different things) are all about proving that code works and will continue to work in the future. … I agree with the others that defining boundaries between people can be counter-productive, though I do think defining boundaries between activities can be useful.
Eric emphasized the right word in his message. I take it and build:
- The test mindset discovers what the dev doesn’t know; the dev mindset proves that it learned that.
- Each human in the team switches between both mindsets based on what he doesn’t know right now. He either knows he doesn’t know something (be dev), or he doesn’t know he doesn’t know something (be test).
- Map the above across: {process, leadership, communication, team dynamics, code, design, planning, …}, simultaneously.