Allow me to explain.
I'm not talking about full-blown TDD, but simply about a beginner trying to write some tests in order to make sure code is working as expected in as many cases as possible. What I almost invariably run up against is my own questionable design choices that usually boil down to three issues: lots of dependencies, needing non-trivial data for a meaningful test, or needing a full ASP.NET web request for a meaningful test.
Sure, some classes are small and simple and will have clear tests supporting them. A few more classes will interact with those first ones clearly and cleanly, too. That'll be about ½ of 1% of my total system. While trying to write tests for the rest of the code I'll be mumbling
"How the heck am I going to test that?"The more I think about testing my own code on current projects, the more I understand the usefulness of TDD and that the goal is not simply tests but an easily consumable, testable design. I've read Pragmatic Unit Testing for a baseline. Hopefully The Art of Unit Testing and Clean Code will help me avoid painting myself into these corners in the future. In the meantime, I've been watching James Shore's Let's Play TDD series, which is really cool because you're essentially looking over his shoulder as he works on a small app.
"Ugh. I need to inject that into that into that just to test one method."
"Why would I write it like this? Was I in that much of a rush?"
I've started to wonder if other people feel the same way and if they avoid testing because of it or if they realize that it's a learning opportunity.
No comments:
Post a Comment