All the programmers in my team are familiar with unit testing and integration testing. We have all worked with it. We have all written tests with it. Some of us even have felt an improved sense of trust in his/her own code.
However, for some reason, writing unit/integration tests has not become a reflex for any of the members of the team. None of us actually feel bad when not writing unit tests at the same time as the actual code. As a result, our codebase is mostly uncovered by unit tests, and projects enter production untested.
The problem with that, of course is that once your projects are in production and are already working well, it is virtually impossible to obtain time and/or budget to add unit/integration testing.
The members of my team and myself are already familiar with the value of unit testing (1, 2) but it doesn't seem to help bringing unit testing into our natural workflow. In my experience making unit tests and/or a target coverage mandatory just results in poor quality tests and slows down team members simply because there is no self-generated motivation to produce these tests. Also as soon as pressure eases, unit tests are not written any more.
My question is the following: Is there any methods that you have experimented with that helps build a dynamic/momentum inside the team, leading to people naturally wanting to create and maintain those tests?
Best Answer
This is the point you need to address. The culture of your team needs to change such that not writing tests during the sprint (or whatever unit of time you use) becomes just as much a code smell as hard-coding values. Much of that involves peer pressure. Nobody really wants to be viewed as substandard.
Do the tests yourself. Visibly berate yourself when you don't do them. Point out where a "good" programmer would've caught that bug if they'd written unit tests. Nobody wants to be bad. Make it that this undesireable behavior is bad and people will follow.