In software development, knowing how to do things seems to fall into three stages.
Ok… let’s pretend it does, it’s bound to be more complex than this, but this is a useful model, so bear with me.
- Facts – you’ve read how something works and how to get going with it
- Lots of experience driven fixes – you’ve hit some problems, used StackOverflow to solve them, have some things that seem to work, generally you think you know the score, though there may be some hole in your knowledge
- Integrated – a lot of what you’ve experienced and read about comes together to form a mental model which seems to extend beyond your immediate experience – you feel how to use something
It’s probably worth looking at this model in terms of any technology or skill you have. Be honest, are you in the basic knowledge with fixes stage, or have you integrated? Are you suffering from the Dunning-Kruger effect?
How does this work in TDD?
It’s odd to say this, but the construction of test code and the motivation behind it is not the same as for production code. It also works best when production code flexes to meet the need for testing. This, for me, leads to the following maturities of test driven development:
- Dabbling
- Peak Test Cray Cray
- Calm and simple
These are worth explaining further.
Dabbling is when we have the idea that we should write tests and we make some, but we don’t make it the core of our development process and we generally avoid anything that’s too hard.
Peak Test Cray Cray comes when a combination of mandate, over keen developers, bad examples from the internet, and inflexible or overflexible design (see Test Smells) culminate in a weird soup of tests and code that are no use to nobody! I think this happens with test techniques as well as the general application of tests to code. I think you have to go through Peak Mockito for example, to learn when not to use it!
At some point you get tired of getting tired of the challenges of testing…
Calm and simple is where you need to be. Some people would argue that this comes from small incremental RED -> GREEN -> REFACTOR steps, definitely test first. The truth is that you need some positive examples to head for to know how to apply the techniques, and you may need to be burned by Peak Test Cray Cray to be open to valuing the calm and simple lands beyond. Hopefully some posts on here will help.
Humility
This is an opinionated site with lots of recommendations on it. In these posts, I explore my own experience in order to get to level 3 of my knowledge. That said, you have to be continuously open to reevaluating what you know. I, for instance, scoffed at the idea of using mocks less when it was first suggested to me, but now I look hard at tests for signs of overmocking.
Your experience will teach you and you should be excited for which opinions and approaches you may come to change or evolve going forward.
Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: The Three Stages of Knowledge Opinions expressed by Java Code Geeks contributors are their own. |
