I've been working on my "super duper mucho excellente" windows service project and the obvious questions pops up "How do you debug a windows service?" I've been told "Use a console/windows program to drive the business logic of the windows service". But I'm lazy and the prospect of maintaining another project/application just to debug a windows service is too much work for me.
Another alternative is attaching to the process using "Debug...Processes...Attach". However, by the time I attach to the process, the program has already ran past my breakpoints. What was I to do?
So off to Google I went and harvested the world's wisdom while munching on donuts.
I saw this post by Paul Ballard.
Now I can say, "I've learned something new today!"
I've just had fun playing around
http://www.dontclick.it
You'll have a severe case of mouse click withdrawal. ;-)
I've been learning the how's and why's of unit testing and test driven development these past few months. It's been a struggle to follow the "write the tests firsts" since by habit, I code first then test. However, following the maxim 'to follow the rules first before tweaking them', I have come to appreciate the 'why' of test first development. In fact, I've come to believe I've produced much cleaner code these past months by just sticking to the 'Red-Green-Refactor' rhythm of tdd.
The biggest gain is really made by adopting the tdd principle wholesale first to really understand what its all about. It needs an 'infect-mind-first' approach so that the 'test-before-code' comes in naturally.