A day of testing...

September 29, 2011 Back to home

Today I wrote several unit tests, and improved our code coverage to the component to 100% (according to Visual Studio). Now, what did I learn from that?

Writing test cases takes time
Improving code coverage is tedious
TDD helps improve code quality and is a good practice

A lot of people will wonder why TDD will be a "good practice"... the arguments are this: It takes twice as long to write test cases then to write the code to make the test pass. Unit tests are one thing, but writing tests for everything is just a waste of time, we don't really gain anything in code quality other than a silly metric for people to measure. I prefer to work alone and get more accomplished in a short amount of time.

Now, for anyone who knows me, I agree with those... I sit here alone, writing this. I get more done when I am alone then when I have to justify everything I do to another person. Now, that being said, that is NOT the intent of TDD. In theory, it is great, but the problem is the human ego. Another dev wants to tell you how to write your code, a tester wants to bring up random tests that are pointless but makes them feel like they thought of something you didn't... But that is NOT THE POINT. The point is this, write a test case to determine what is the expected behavior of what you are going to code... then code it to make this behavior happen so the test passes. That's it. Don't create 4 layers of classes with interface subclassed from another parent class because you may want to reuse it one day and abstract things just to abstract it. STOP ENGINEERING FOR NO APPARENT REASON. MAKE YOUR CODE SIMPLE. We don't need to know how smart you are... if you make your code simple and readable, you are smarter than most developers I have worked with. Why? because they are insecure in their abilities that they create more and more complexities causing it harder to maintain. It helps them feel like they are needed in a company. I would rather write code so elegant and SIMPLE that a grade school student could read it, understand it and maintain it. Why? Because if I write code that simple and it works, then they don't need ME to maintain it, because it works.

Sorry, got a little off topic there. TDD, is a good practice and the more you do it the easier it becomes, you write your code naturally in a way that is testable and maintainable. You adhere to good coding standards naturally, because someone else is looking it. Code reviews occur automatically. It has great potential to improve your code quality. TDD is great process (coming from someone who HATES process). BDD is the new thing, and that is a topic for another day. BDD is NOT A TEST. It is a scenario, a workflow, an expected behavior. BDD IS A PROCESS NOT A TEST. Ok, one last rant, UI level testing is the LAST level of testing that should be done, IF AT ALL (yes, I said it). I'm a dev, I will always be a dev. I don't have the mindset of a tester. I don't have the mind of a designer either (I've tried). I can do enough of both, but those are not my forte. But we all have our callings, my wife is an amazing singer, I am happy developer, my friend Ryan is an amazing dancer. We all have our callings and they are not the same. But back to the topic, (I haven't written in a while, so a lot is stored up in the random brain I have, yes, it is generally pretty sequential).

Anyway, write your tests, write your code, watch your tests pass and move on. :-) Ok, that's all for now. Thanks for stopping by.