I don’t test my code and you shouldn’t either.

Wait, what? I am sure about now you are saying something like “Not testing your code is asking for trouble.” Let me clarify, I do not test my code through the UI.

It started about a year and a half ago. I was given a task to write a trigger for a client. The only problem was they had hit the data limit in their Salesforce sandbox. While my project manager worked on getting permission to delete records, I had work to get done. How was I going to do it if I couldn’t create records? Then it hit me, I could use test classes to test my code. This one simple thing changed my programming style. I wrote the code, and wrote very robust test classes at the same time. They had to cover everything I could think of. I couldn’t create a record in the Salesforce UI. When it was done, I had very well written code, and my tests were also complete. Fast-forward a week. We had deleted records and freed up space. The client was testing the trigger we had made for them. They came back with “It’s not working.” I asked for the exact information they were putting in. I went right back to my test class. I copied a test which tested this exact scenario, and inputted their data. I ran the test and it passed.  Upon explaining this to the client and walking through it again they realized they had miss calculated when they did the calculation manually. The code was correct.

This started me down the path of test driven development. This has great merits in programming, however, for me, in practice it often gets pushed aside. I started doing a mix of development first and test first development.

Here is how I program

1. While I am programming when I realize “This piece of code should be its own method.” I move it to its own method. (See How to Eat an Elephant for more info on how I do this.)
2. Next, I write the test. As soon as a method is created a test is created. I build the test from the perspective of not knowing what happens inside the method. I know that I have to pass these 2 variables in, and expect this result back. (Black Boxing)
3. Next, run the test. If it passes good. If it fails I go back to my code and re-factor.
4. Only once I am completely done and every line of code is tested do I test in the UI. I know I said I don’t test in the UI. I don’t while developing. It is a final sanity check. I fully expect at this point for everything to work.

One final note, this is not a hard and fast rule of programming. Sometimes I will create the test first, then code. The one rule I do follow is always test everything while developing. Going back later and writing test classes is not only harder, it just isn't much fun.