The bar has been raised
With a couple much-appreciated pointers from MikeD, today I took my past dabbling in Apex code and refactored it as Classes and Methods called by Triggers. It’s a better way to organize the code, and makes it more maintainable.
Then, I started building tests. Andrew, Jon, and David do all their Python programming in a test-driven fashion, so I understand how it works. But I’ve never done it. This afternoon I got built out tests to cover the Apex code I wrote automating the Householding process.
I now have tests that cover just shy of 100% of the lines of code I’ve written to automate Householding. That means that by clicking a button in Eclipse I can evaluate 5 triggers and 400 lines of heavily conditional code in about 5 seconds.
If I want to verify that the Household name actually changes when I add a Contact to that Household, I don’t have to go to the UI at all. I run my tests and it shows me what is happening. Without ever writing any data. In 5 seconds. I’m floored.
While I was writing the tests, the Apex plug in for Eclipse was kind enough to show me the lines of code I hadn’t covered yet. Amazing how helpful that was. Thanks Dave!
I sure have a lot to learn now that the bar has been raised, because I’m really just a script kiddie. But the learning I’ve done today has already paid off. Tests are the gift that keeps on giving!
September 27th, 2007 at 5:23 pm
W00t! Test-driven development rocks. It’s how you PROVE that your new code doesn’t break your old code. That’s huge. It’s a shame that more folks in the nonprofit tech community don’t seem to value this approach.
September 28th, 2007 at 10:03 am
Steve…do you have a screencast of the Household apex functionality yet? Really looking forward to seeing Apex in the nonprofit edition and your brilliance adopted by the lot of us.
RE: Jon…I don’t think most in the nptech community know what the hell you guys are talking about…I just barely do.
September 28th, 2007 at 10:33 am
I will do a screen case when we get this hammered out in the next couple days. The biggest benefit right now to building this in a test-driven way is that I can make changes and run the test to see if it works. I don’t have to go to http://www.salesforce.com and use the UI to see the behavior. Incredibly more efficient.
Example: I didn’t handle the case where if one spouse changes their last name that the HH recognition name should change. So, I created a test for that. Just took a Contact, changed the last name, and then checked to see if the HH recognition name had changed. The test failed, as expected. Then I wrote the code to handle that case. Then I clicked the test button again and the test passed, meaning my code worked. Awesome.
I need to read up on test-driven development, and object-oriented programming in general now that I’m using this new powerful language. Every day is a learning day…
September 28th, 2007 at 9:48 pm
Raising the bar, indeed. You are scaring me.
Even with Apex, we’ll still have s-controls. Can we somehow automate testing them too?
September 28th, 2007 at 10:42 pm
I remember long ago reading (I think) about a test harness for the AJAX toolkit. I had no idea what that meant at the time…and haven’t heard anything since.
I think in the future we can off-load a lot of the logic to Apex, and have s-controls that call those blocks as web services. I hope to have my first example of that built this week–an S-Control that clones an Opportunity along with the contact roles. Right now that’s an s-control with no UI. Should be easy to rewrite as an s-control where all it does is call an Apex method, passing in the id of the Opp to be cloned.
Then you can test the Apex and effectively test the s-control. For s-controls where you can’t off load everything, I suppose we’ll keep doing things the way we are now. But I’m open to suggestions, for sure.