I'm having trouble finding the article I wanted to reference for this, so bear with me. :)
ncrunch / continuous testing helps lower the mental barrier to running tests, but for people not used to TDD (or even testing), it's not a very 'engaging' experience.
There's already been some areas of development where gamification has been used well (for instance, perf, specifically frame rate, of a game did better after one of the developers put a happy/sad face next to (or instead of, I don't remember) the frame rate indicator.
Similarly, I think code coverage is something where the raw numbers are a little too boring and some emotional attachment would help developers, especially those less familiar/inclined to testing.
This certainly isn't a new thought, there's already others trying something similar (going back to things like a version of Doom for 'killing' bugs), but NCrunch seems like it's potentially in a position to either adopt something like this, or expose it as an extensibility point for others.
Remco NCrunch Developer
#1867
16 May 2012 05:09 UTC
Hi James -
I can certainly see a connection here between NCrunch and gamification. Many people comment on how getting the markers to turn green seems like a game. Most likely this stems from the the fact that NCrunch gives you near immediate positive/negative feedback on success or failure of your coding efforts.
It's quite a refreshing viewpoint to take on a tool like NCrunch. Most of the time people think about testing tools as simply being a way to improve productivity or the reliability of their software, and while this is the goal of NCrunch, it never hurts to make things fun.
IMHO, the true challenge of gamifying coding is to find a way to mechanically encourage people to write better code. The scoring of what is 'better' can, however, be very subjective. Code coverage in itself can be a good example. 100% code coverage is a common goal for many projects - though were I to work on a project with 100% code coverage, I would be asking whether developers were chasing for reliable code or for better metrics. I have worked on project teams where team members were praised or berated based on the metrics of the code they wrote, and in retrospect I can't say I agree that it made the system any better.
This isn't to say that I think gamification of TDD/BDD is a bad idea. Actually, I very much like the idea and would be interested in exploring it. The devil is very much in the detail.
I can certainly see a connection here between NCrunch and gamification. Many people comment on how getting the markers to turn green seems like a game. Most likely this stems from the the fact that NCrunch gives you near immediate positive/negative feedback on success or failure of your coding efforts.
It's quite a refreshing viewpoint to take on a tool like NCrunch. Most of the time people think about testing tools as simply being a way to improve productivity or the reliability of their software, and while this is the goal of NCrunch, it never hurts to make things fun.
IMHO, the true challenge of gamifying coding is to find a way to mechanically encourage people to write better code. The scoring of what is 'better' can, however, be very subjective. Code coverage in itself can be a good example. 100% code coverage is a common goal for many projects - though were I to work on a project with 100% code coverage, I would be asking whether developers were chasing for reliable code or for better metrics. I have worked on project teams where team members were praised or berated based on the metrics of the code they wrote, and in retrospect I can't say I agree that it made the system any better.
This isn't to say that I think gamification of TDD/BDD is a bad idea. Actually, I very much like the idea and would be interested in exploring it. The devil is very much in the detail.
Post a reply
Log in to reply.