Interestingly I find my TDD acceptance is very different when working at home on my open source code than at work. Clearly my home code suffers for the lack of unit testing. Apps take longer to develop and are ... hmmm ... less reliable.
So why do I do this? I have plenty of experience to know that TDD reduces development time.
Thing is each time I go to do a commit (at home), while looking at the TV over the top of the laptop, the name NUnitCoverCop runs through my thoughts. At work I know that if I make any commit that reduces coverage NCoverCop will fail the build. Funny thing is, I find this liberating. It removes the temptation to just make that one little commit. I think everybody in the team thinks the same.
So does NCoverCop's acceptance lead to TDD acceptance or follow it? You would think we would find it a hinderance, but instead we find it liberating.
1 comment:
Hi Nigel,
Interestingly I find my TDD acceptance is very different when working at home on my open source code than at work. Clearly my home code suffers for the lack of unit testing. Apps take longer to develop and are ... hmmm ... less reliable.
So why do I do this? I have plenty of experience to know that TDD reduces development time.
Thing is each time I go to do a commit (at home), while looking at the TV over the top of the laptop, the name NUnitCoverCop runs through my thoughts. At work I know that if I make any commit that reduces coverage NCoverCop will fail the build. Funny thing is, I find this liberating. It removes the temptation to just make that one little commit. I think everybody in the team thinks the same.
So does NCoverCop's acceptance lead to TDD acceptance or follow it? You would think we would find it a hinderance, but instead we find it liberating.
I think it followed. Hmmm.
See ya
Rob Smyth
P.S. I want a non-nant NCoverCop!
Post a Comment