Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
7  
Disappointing if plus and minus votes are being offered on whether the OP is using appropriate gender form. Surely the quality of the question is in what is being asked and its relevance to the site, and not on subjective views of whether the inclusion of both he's and she's are to be considered sexist or not. This kind of friendly bickering really won't help the reputation of the site... or those involved. (I'm just saying!) –  S.Robins Jun 25 '12 at 11:34
    
@S.Robins, You're right and I wouldn't upvote if I didn't think this isn't a good question. But the comment is offensive anyway. And when I see such things quite often among programmers I just can't hold it in myself. –  superM Jun 25 '12 at 11:41
2  
@superM LOL! I know what you mean. Overhanded political correctness gets my goat. I tend to write either entirely gender neutral, or use "he" exclusively simply because it's kind of natural to relate such references to your own gender. My comment was however intended to be more generally applied, and not specifically to call out any particular individuals. ;) –  S.Robins Jun 25 '12 at 11:46
1  
I've purged some of the comments. +-1 comments are pure noise and should be avoided when they don't add anything useful to the post - read our comment privilege page for guidance, and please take such conversations to Programmers Chat. As for offensive comments, please flag them as such. –  Yannis Rizos Jun 25 '12 at 11:47
1  
Thanks guys, ymmmm, people ))) –  superM Jun 25 '12 at 11:48
add comment

6 Answers

Getting an entire team to all actually want the same thing can be quite difficult. It's often the case that seeing the value in something isn't enough in itself to encourage people to change ingrained behavior. Even those who value the change and who specifically want it can sometimes also be responsible for subconsciously fighting it.

The issue is really one of individual motivation and not team motivation as such. There comes a time when a moment of clarity reaches you, either as a result of something you felt you finally understood, or because of some new tool or some other subjective thing that makes the average programmer throw everything in and completely change the process. Your job - should you choose to except it - is to see if there is a way for you or the team to find out which things will be the triggers of clarity for each individual team member.

For me personally, it was simply discovering the StoryQ framework for BDD in DotNet, which made it too easy to ignore, and got me completely over the test-first vs test-simultaneously "barrier". Later I had my choices reaffirmed when I found NCrunch for Visual Studio. Half the battle sometimes isn't in selling the idea, but rather in simply lowering the effort required to introduce radical change in habits... and even then it can take a little time and work. These same personal triggers however weren't enough to sway the approach of my colleagues at the time, who are still writing as much of their test code simultaneously or even after their implementation code.

Sometimes also, there is a reluctance to change the way things are done, due to an inherent fear, distrust, or distasteful view of the effort required to learn to do something differently, even when the reasoning for the change is sound. If your entire test platform is tooled to work in a specific manner, it can be hard to justify changing the way things are done, and potentially changing the tooling, especially when old and new tests will need to continue to coexist for the lifetime of the project - and you certainly wouldn't want to need to rewrite every test you ever created. The strange thing is that sometimes people feel that this is the only way to adopt a new testing methodology, and that in itself makes it harder for those people to accept sensible change for the better.

Really, the only way something becomes reflexive is to force yourself to do it over and over again until you no longer notice yourself needing to concentrate overly much on how to do it. Sometimes, the only way to do this in a team is to set policies which may seen a little draconian, and to practice pair-programming and code-reviews, and anything else that can help team members back each other up and literally force the change in behaviour to occur. However, for such a strategy to really be successful, it still requires a firm and honest commitment from each and every individual team member to accept such measures as necessary, and to participate in the process... and a lot of patience from all involved.

share|improve this answer
add comment

None of us actually feel bad when not writing unit tests at the same time as the actual code.

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.

share|improve this answer
    
+1 for the culture change, and would that I had another +1 to give you for leading by example. Nice answer. –  Erik Dietrich Jun 25 '12 at 13:47
add comment

first you'll need to ensure that writing a test and running it is easy, get the framework set up in the current projects and make that set-up procedure simple to include in future projects

this way when a programmer wants to unittest a new feature he is trying to debug he doesn't have to jump through a dozen hoops to get the tests running properly

the more akward something is to do the less likely it is you'll make a habit out of it

share|improve this answer
add comment

One thing I've done that's been somewhat successful in instigating a culture change is to set up a weekly drop in, "unit test curation" seminar. The official purpose of this is to help keep the unit test suite fast running and up-to-date, but the more important purpose, in my mind, is to give people a low pressure way to drop in, ask questions, and practice testing. The fact that you're willing to spend an hour or whatever per week exclusively on the tests also sends the message that this is important.

I think that you get a bit of a culture change this way and you start to remove the barrier to doing it "reflexively", as you put it. People will tend to revert to old habits at the first sign of adversity -- having a meeting like this won't fix that in one fell swoop, but I think it'll initiate a culture change and remove the barrier that results from not really knowing what you're doing.

share|improve this answer
add comment

None of us actually feel bad when not writing unit tests at the same time as the actual code

Not sure what you mean by "at the same time", but how about writing them before the actual code ?

It's easily understandable from a psychological perspective why any human being wouldn't want to bother writing unit tests after the code. At that point the code is already working, so why on earth should we need to test it ? Some kind of laziness automatically takes place because it's tedious, seemingly useless and not writing tests doesn't appear to be dangerous. As a result, I don't know of many teams that kept on with a test-after approach over a long period of time.

In my experience, test-first (TDD style), however, is something you can quickly get addicted to because there are at least 2 immediate, tangible, endorphin-releasing benefits to it :

  • It helps you design your code face to face with concrete executable requirements and make the design better and better as you refactor, which is much more purposeful and gratifying than just double-checking something that already works.

  • The TDD cycle is punctuated with frequent "green bar" moments where you can enjoy the taste of immediate success. It constantly keeps your mind satisfied and ready to go for the next feature to implement.

So I wouldn't attempt to make your team feel bad when they didn't write the tests. Instead, I'd try to make them feel good as they do. TDD is one way to do this.

share|improve this answer
2  
Another nice benefit to TDD (especially with a continuous testing tool) is the fast feedback. In a large code base where building and running the software can be on the order of minutes, TDD/CT drastically speeds up feedback and thus development. –  Erik Dietrich Jun 25 '12 at 14:10
add comment

To have a group of programmers in which all naturally want to do something is an utopy (especially when talking about a large group).

Unit and integration testing is a thing of standards. You create a standard for an workflow and each member of the team should respect it. The standards should be made with the aid of QA professionals, because they know it better. An programmers should respect the standards. What you can do is make the standards clean, easy to understand and follow.

It is not about trust in your own code and desires to use, it is about needing to have coding and testing standards that everyone use in order to make good things, and any programmer should understand this.

When you make people from the start follow the standard, it becomes a reflex and it will be followed. Making it a rule that no code can be put in the codebase without a unit test would convince people that they have to do it. For project repositories there are even more restrictive rules. For example, companies make unit tests before actually coding the unit (when they make the module specification) and this is a very good method. If a programmer puts code in the project/codebase the code is run throught the test module and if the unit tests don't pass, they go back to work.

If it is hard at the moment to add standards and rules, at least think of adding them in future projects.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.