FWIW, in addition to TDD, there’s a cool thing out there called Design by Contract or Programming by Contract. It’s not appropriate for every programming challenge, but it’s a useful frame of reference to have in your bag of tricks.

Cheers!

All my testing to date has been unit testing. One of the great things about VisualForce is that if I use standard components, all that integration testing should already have been done by Courtney’s team down at Salesforce!

On the Plone side, one point that I’ve found helpful is the distinction between unit tests and integration tests. Unit tests focus on a particular function and make sure that it behave properly for a range of different inputs. Integration tests test the system as a whole and make sure that everything is wired together properly. For the latter, we use the zope.testbrowser package which lets us write Python code that mimics a web browser and can click links, press buttons, etc. (no real rendering or Javascript support though — for that you need something like selenium)

This post also raises the question — does ONE/Northwest have any developers who have taken a real CS course? I only lasted a day in the one I tried…

The “Apex Test Coverage Best Practices” session from Dreamforce is a great resource for developers intrested in Unit Testing in general: http://www.salesforce.com/community/crm-best-practices/dreamforce08-developer-sessions/2008-tdf-mastering-apex-best-practices.jsp

These are great tips. I love them all and will be incorporating them in my daily coding practice (sounds like yoga when I say it that way…)

Like most software dev projects, long term success is defined by low cost-of-change over time (aka ‘Agility’).

Some things I’m conscious of when coding with unit tests:
* Test-Driven-Development: Write a unit test first that most elegantly documents the desired object interfaces and control flow, then write actual classes to make the test pass. This qualifies as formal ‘design’ in agile projects.
* 500 line rule. Time to refactor if any file/class gets over 500 lines.
* 5 minute refactoring rule. Approach larger problems as a series of smaller 5 minute refactoring drills; each with corresponding unit test changes (I dread refactoring lots of code then having to go back and clean-up tests).
* Self-Documenting: Write tests as a means to describing and documenting the intended usage of the system. A self-explanatory method or test name is preferred over comments.

@IsTest is the same as testMethod, but it appears it does except that code from the total 1 MB limit for all Apex code. Glad I’m not anywhere near that big!

Use the @IsTest keyword. I think this means you need to put your Tests in separate classes, though. Adding this keyword makes it so the test code doesn’t count against your code limit. This may not matter if you are not coding heavy amounts.