I few weeks ago, while attending the Central OKC Java Users Group, the presenter asked for a show of hands for how many people had actually used EJB 2.0. In a crowd of over 50 java programmers. If anyone raised their hand, I didn’t see it. You mean to tell me that I suffered guilt and shame over not using EJBs for years for nothing? You mean to tell me that I was suffering under the delusion that I was the only java programmer who thought that EJB 2.0 seemed cumbersome and of little value given the effort? Geezaloo! I thought EVERYBODY was using EJBs…at least until POJO frameworks gained popularity. Just goes to show you, don’t drink the Kool-aid unless you see it mixed and poured with your own eyes!
Enter Automated Unit Testing. For years now, I’ve read about automated unit testing with JUnit. I’ve read articles about it. Done tutorials where I test a method that takes two integers and adds them together. I’ve suffered guilt and shame for not doing automated unit testing. I’ve also suffered in trying support my own buggy code. And when I’ve tried to write unit tests for real-world scenarios, I’ve struggled to figure it out. I asked a veteran java programmer if automated unit testing was mixed from the same batch of Kool-Aid that EJB 2.0 was mixed. She assured me that it wasn’t. And now I know that she is right. Automated unit testing is not only achievable, but CRUCIAL! (I say this with a whole 2 weeks of JUnit under my belt)
I’ve been limping along for years testing the unit only to the extent that my functional testing happens to use this unit or that. If something blows up, then I drop a breakpoint and take a look. I’m here to tell you, friends, that this is not sufficient testing. Just in the two weeks I’ve been writing JUnit tests for my code, I’ve uncovered half-a-dozen bugs in a class that had already been functionally tested. These are bugs that had never seen the light of day because the presentation layer could not yet present the unit with enough scenarios. And now, I’m beginning to actually engage in what was previously believed (by me) to be a purely mythical activity that only organizations like NASA engaged in: Test Driven Development. Test and Code, Test and Code, Test and code…whoa! And I’m writing the best code of my life…code that considers all possible scenarios.
One of the toughest challenges I’ve faced so far is when the class that I’m testing depends on outside resources. I’ll take some time later to blog about how I’ve used Spring and Mock Object patterns to simulate outside resources.
[EDIT 5-7-12: To be honest, I didn’t get very far with you unit testing or test-driven development. I must have been high when I wrote this. It’s such a pain in the ass. I still feel guilty and ashamed for not doing it, though! So that’s something! ]