W3matter LOGO
BLOG RETWEETS ABOUT CONTACT US RSS · ph: 786-539-4198

Have a web project?

We'll build your product making sure it's praised by users, loved by google and profitable to you.
Let's Discuss it
Then Develop
and Deploy

Why I ll never do test driven development TDD

Written over 1 year ago by Ericson Smith

Yeah, testing is good, and interesting. I've been programming for a long time (20+ years) , and here's what I do to avoid automated testing (except a tiny bit of unit testing here and there to make sure the whole system does not fall down)
Plan what you're going to do, and document that plan
And even though you do this, that plan will change, your assumptions will change about the  performance or scalability of each feature in your system.
Thoroughly MANUALLY test each method you write.
I can't say this enough... we write stuff in Ruby, and when we write a new method to do something, we test it manually out the wazoo in the console. The same things you test in the console, is the same thing you'd write in your tests anyway. Let me repeat... the same thing you test in the console, you'd write in a unit test. You'll finish much faster.
Write less shitty code
This is probably the most important part. Know your programming language, and implement it simply and well. This can only come from experience too. I've seen young whiz kids bang out code 10 times faster than I could, but you know what, its 50% shittier than my crappy code. Sometimes we tend to show-off our meta programming prowess, when a simple and more bulletproof traditional way could do a more upstanding job. Sure its more boring, but no one is going to knock it over with a well timed fart.
Trust yourself
This one is big. For me, if you can't trust what you write, then your tests are not to be trusted either, unless they are written by someone who did not write your code.
What REALLY needs to be tested
If you run the typical website out there, users generally need to do a few things:
* Signup and Login
* Post their UGC.
Those are the only functional tests we do. And we might do them because we just don't want those things to break at any point during code updates by overlooking something. After many years of doing this, we find that its generally the things that interconnect that might cause something to break. Not the fundamental easily testable things. Why? Because we tested those fundamental things already.
Sure, there is a place for tests. But in my opinion, not in 99% of of typical CRUD based websites out there today. If you're doing some hard science, with ultra-complex algorithms  in your methods, then I can see that. But if you're building a blog, you're just self-preasuring yourself. I'd rather get my stuff out there and get laid by another human being instead.
blog comments powered by Disqus