To debug or not to debug?

After going over the logistics, Eric Meyer, my mentor, told me to write Mastermind in any language that I choose. Considering I took about a week to write Tic Tac Toe, I thought this was going to be a breeze (I was wrong) so I gave myself the challenge of not using the debugger.

I'm not sure if I read this thought from somewhere or if it's my developer instinct. It is not something that I can concretely express or defend yet, but I feel if I write the code and the unit test well, I should immediately know what's wrong with the code. Thus I should never need a debugger to tell me what my code is doing. So on the first day of writing mastermind, I didn't use the debugger at all.  I like to think I did pretty well. I wrote the majority of the code without running anything through the debugger.

My problem came when I tried to figure out how to indicate the color is correct but the position was not. I spent most of my second and third day on this problem. It shouldn't have been that hard, but it was. Whenever I added new code, my tests were failing left and right. I couldn't figure out why. And the debugger devil kept whispering how easy it would be to solved the problem with the debugger. I resisted at first, but by 3PM my mind was too exhausted to fight so I gave up and used the debugger, "just to see why this test case is failing" I said. Well one thing led to another and the next thing I know, I couldn't stop running my app in debug mode.

I admit that was a total fail. I still have that mentality of getting things done. I forgot that I came here to learn, that I should do what I think is a better solution, especially when I don't have a deadline (yet). I should be patience and not rush through anything. What I should have done on day two was look at my tests again, then think, can I really trust my code? Can I really trust my tests? Did I test it well enough that I can confidently say every part of my app work and if there is a problem, I know where it is? The answer of course is no. My code and tests were messy.

I used to write unit tests to test my method. But when I went to a TDD class, the teacher said that I should focus on testing the application's behaviors. It made sense. As outsider, you just want to know if the code works. You shouldn't care about the implementation. So when I wrote my test, I test only public methods. Unfortunately, I don't think this is is working out well. Because I'm testing the class API, I can't guarantee that a certain protected method in the class work. So when I come across a problem like the one I encountered today, I didn't know how to solve it. This could be an indication that I didn't write my code well. That is probably what Eric will say when he sees the code. In fact, he probably won't say well. He'll probably say, this is bad. Do it again.