Agile Zone is brought to you in partnership with:

I'm a writer, programmer, web developer, and entrepreneur. Preona is my current startup that began its life as the team developing Twitulater. Our goal is to create a set of applications for the emerging Synaptic Web, which would rank real-time information streams in near real time, all along reading its user behaviour and understanding how to intelligently react to it. Swizec is a DZone MVB and is not an employee of DZone and has posted 63 posts at DZone. You can read more from them at their website. View Full User Profile

Unit testing is for lazy people

03.01.2012
| 8722 views |
  • submit to reddit

The other day I was talking to a guy about a possible freelancing gig and he said how wonderful it was that I should bring up the topic of unit/automated testing without being asked. He said that most (many?) developers don’t have the level of rigor to use automated testing.

My reaction was one of disbelief “Rigor!? But automated testing is one of the laziest things a developer can do! It speeds stuff up so much!”

As luck would have it, last night I was hit over the head with my own words and nearly died debugging a single function.

I was working on Stripe webhooks and for security reasons decided not to use the event data sent in request body. Makes sense right? Take the event id from request body, then fetch the actual event from Stripe.

It’s the only way to be certain you aren’t responding to bogus events sent by an evil person trying to make you look bad (nothing actually bad can happen, at worst a customer would get extra paid invoice emails).

Due to poor decoupling – I didn’t really want to decouple a 6 line function into two functions – everything was now difficult to test. I can’t create events on Stripe’s servers with unit tests and without actual events existing I can’t test the function works as it’s supposed to.

How many bugs can you put in a 6 line function anyway?

A lot of bugs!

When the client tested on staging … it didn’t work. Invoice email wasn’t sent and Stripe complained of a 500 error.

It took me almost two hours to fix all the bugs because my testing cycle looked like this:

  1. change code
  2. commit to develop branch
  3. switch to staging branch
  4. merge develop branch into staging
  5. push to github
  6. change to other terminal window
  7. pull from staging branch
  8. restart python processes
  9. go to Stripe dashboard
  10. pick customer
  11. create invoice item
  12. create actual invoice
  13. choose invoice
  14. pay invoice
  15. go to Stripe logs
  16. find invoice.payment_succeeded webhook
  17. scroll down to response
  18. look through raw html of django’s error page
  19. find symptom
  20. GOTO 1.

That’s right, a whopping 20 step debug cycle all because I’m an idiot and couldn’t find a way to automate this. Or maybe I was too tired to do the unobvious thing … although I still don’t want to split a 6 liner into two functions.

With proper unit testing the debug cycle would look like this:

  1. change code
  2. run tests
  3. symptom thrown in face
  4. GOTO 1.

Much lazier right?

For the record, those six lines of code contained 4 bugs ->

  • forgot to import a module
  • different event data structure than I understood from the docs
  • twice^
  • misnamed variables from one line to another

Yes, all of those could easily have been caught if my test coverage was actually any good! And then not only would I not look like an idiot in front of the client, I’d probably spend no more than ten minutes fixing this.

 

From http://swizec.com/blog/unit-testing-is-for-lazy-people/swizec/3752

Published at DZone with permission of Swizec Teller, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Mason Mann replied on Thu, 2012/03/01 - 7:45am

I know ZERO good programmers who do unit testing. It's so idiotic I can't believe people are still doing it when the right answer is code review. Don Knuth was right all along... as usual.

 

Unit tests invariably misses important bugs because the tests are out of date, not covering enough ground or buggy themselves, and to make things worse - they make people NOT want to properly refactor code because it breaks the tests. That's pretty lame. 


Unit testing is for morons. Are you one? 

Liam Knox replied on Thu, 2012/03/01 - 7:58am in response to: Mason Mann

I think this is perhaps the most moronic comment I have ever read.

 Christ you can barely write English.  Please don't tell me you try and code also. 

Mitch Pronschinske replied on Thu, 2012/03/01 - 10:08am in response to: Liam Knox

Let's keep the comments constructive and polite please :)

Attila Király replied on Thu, 2012/03/01 - 11:29am in response to: Mason Mann

Look into TDD when you have some time. Test-driven development cycle

Chuck Dillon replied on Thu, 2012/03/01 - 11:44am

To the original post...  Am I getting this correctly?  You had some code that you couldn't unit test but needed to system test.  Apparently you didn't system test but pushed it to staging where someone else would do the system test.  If I have that right your "look like an idiot" sensation has nothing to do with test methods, it's apparently because you didn't test?

Another possibility is that you didn't do a good job system testing which makes this a valuable learning experience.  One common thread I see with current generation developers is that they often are so focused on applying unit testing frameworks/paradigms (e.g. xunit et al) and are so overly confident that coverage means good - they are often just bad at testing in general, particularly at system testing.

To your, it's just six lines of code, scenario - we've all been there.  You have a small amount of code with broad and complex dependencies.  Do you use an inefficienct (e.g. 20 step) debugging cycle or do you build a potentially complex test harness?  It's a judegement call we have to make from time to time.

Karl Peterbauer replied on Thu, 2012/03/01 - 12:32pm

Hmmm... Forgot to import a module, different event data structure than understood from the docs, and misnamed variables twice in just 6 lines of code? I don't want to start a flame, but maybe that's more an argument for using a strongly typed language than for more unit testing...

Erin Garlock replied on Thu, 2012/03/01 - 2:02pm in response to: Karl Peterbauer

Karl, I was thinking the same thing.  I've coded in just about everything under the sun (anything older than 5 or 10 years anyway), and after a bout of searching for an X vs. x for 24 hours once I'm a firm believer in strongly typed languages.  Of course, in keeping to this thread, had I had decent tests I probably could have found it in 24 minutes instead.

Mason Mann replied on Thu, 2012/03/01 - 4:40pm in response to: Liam Knox

My english is flawless and I do code. I'm not as moronic as you though, so I actually make a lot of money doing it, without a single line of idiotic test code.

Liam Knox replied on Thu, 2012/03/01 - 5:55pm in response to: Mason Mann

I rest my case

Mason Mann replied on Fri, 2012/03/02 - 4:14am in response to: Liam Knox

Me too! Donghead.

Liam Knox replied on Fri, 2012/03/02 - 5:48am in response to: Mitch Pronschinske

the quality and this sight has gone to shitevery post: not relevant
what are you going to do

Witold Szczerba replied on Sun, 2012/03/04 - 9:46am in response to: Mason Mann

 I know ZERO good programmers who do unit testing. It's so idiotic I can't believe people are still doing it when the right answer is code review.

Misko Hevery was right. Once he said that writing testable code is a skill most of the progeammers just do not have. More than that: they will never ever admit it. He also said, it takes about 2000 hours working on a project with proper coding practices to actually get how to write and maintain tests (a.k.a. executable specs). Without proper knowledge, tests are brittle and they turn against developer.

What also characteristic, all the (so called) tests haters always bad-mounth them providing worst testing related practices ever.

Some time ago I saw a wondeful presentation called "Why You Don't Get Mock Objects", by Gregory Moeck:
http://www.confreaks.com/videos/659-rubyconf2011-why-you-don-t-get-mock-objects
During this presentation he says, among others, something very very clever:

When smart people invent something and then you think: "Hey man, this is so stupud", do not say that to anybody, until you actually understand it. Then if you want declare it is stupid - that is fine, but make sure you understand it before you start talking, or you going to end up like a fool.

---
Regards,
Witold Szczerba

Mladen Girazovski replied on Mon, 2012/03/05 - 6:54am

Due to poor decoupling – I didn’t really want to decouple a 6 line function into two functions – everything was now difficult to test.

 You should have splitted the method. 6 lines of code is by no means to small for refactoring.

As for the rest, wrtiting unit tests is easy (if you write testable code), but a lot of unit tests will make some considerable sized code, and this code needs to be maintained (refactored, avoiding redundancies, decoupling dependencies,  etc. pp.), if you fail to do this, your test suite will slow you down when writing prod code. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.