|
I've recently switched jobs. At my previous job, everyone wrote tests and we were all in a happy place. In my new role, I've been asked to setup CI and testing. I'm experiencing some resistance to testing from some developers and wondered if anyone had experienced this and had strategies for dealing with resistance? |
||||
|
|
|
I would say that the best way to overcome such resistance is to lead the way. If you stick to writing tests, you are very likely to gather empirical evidence that it is a good thing to do. Hopefully your code will contain fewer bugs, the bugs will be quicker to locate and resolve and so on. If the other programmers in the team has the least interest in quality, they will probably also become interested in your approach. My experience is that it is very hard to force developers into testing, but that they get a more positive attitude after seeing it around for a little while, and eventually move over to testing more voluntarily. |
|||
|
|
|
I'd start (and in fact in my new job I did start) by getting CI up and running to begin with. Show them the advantages of that first - no more broken builds. Once they are convinced of the benefits of that, then show them how you can gain even more benefit by adding regression testing - proving that new check-ins don't break old functionality. From there it's just a case of getting them to protect the code they've just written from future checkins - i.e. writing unit tests that show what it did when they wrote it and protect it from future corruption. |
|||
|
|
|
Show your collegues how unit-tests illustrates bad design by the "if its hard to test something's wrong" rule. Thats how I FINALLY got it :-) Also, you could give them a challenge: Show me some code that cannot be unittested, and I'll show you wrong by doing it, while making your code even prettier than it already is. My colleague threw this challenge at some teammembers that had not yet seen the light :-) |
|||
|
|
