Test Driven Development In The Cloud…

Software as a Service (SaaS) is a form of Cloud Computing that delivers a single application through the browser to thousands of customers using a multitenant architecture.  SaaS has gained in popularity in the past few years, and with it came some dramatic shifts in architecture and design.  For instance, restrictions on processor usage and database queries have become common place due to the nature of the distributed environment.  However, as developers we need to be careful to avoid using this paradigm shift as an excuse to deviate from the development practices we know to be successful.  Like Test Driven Development…

Regardless of the development environment, if you can unit test, you can practice Test Driven Development.  As an example, let’s look at the best known and most successful of SaaS enterprise applications, Salesforce.com (Author note:  I chose to highlight Salesforce for two reasons: 1) It offers a unique testing engine that many people think is detrimental to TDD, and 2) I have been developing custom Salesforce applications for less than a year, and I think it is really, really cool.;) ).

Custom applications are written using Saleforce’s proprietary language, Apex, which resembles Java.  It also carries a testing engine, which allows you to specify test classes and method via naming convention.  The hitch with Apex is that developers are not able to run test locally.  All Apex code, including unit tests, must be executed in a Salesforce server.  That means that a developer must save code to the server before testing it.

All true TDD aficionados should be cringing at that thought.  Remember, the first step in TDD is creating a test and watching it fail.  Are we really committing failing tests to the server?

Don’t worry.  It isn’t as bad as it seems.  The first thing we need to do is realize that we are not (or at least better not be) developing Apex applications directly in the production environment.  Salesforce allows developers to create new developer accounts for each project they are working on.  Through the magic of XML and Eclipse, transferring environment details between accounts is fairly easy (and the subject of my next blog...).  So new code, and the related unit tests, are developed in the developer sandbox.  Instead of looking at this sandbox as a server, think of it as your own personal dev machine (that you can conveniently access from any computer with a browser).  When we create a unit test and verify that it fails in this development environment, it is really no different than doing the same thing on your local machine.  Failing tests are OK.  The idea is to ensure that all of your unit tests are passing before passing along those changes to central repository…

And this is the trick.  I am leading a little into next week’s blog, which will focus on collaborative development in Salesforce, but the trick to treat the dev account that you work in as your local dev machine, and have a separate account for the central repository.  (I can see the light bulbs going on now, but come back for my next blog anyway - you won’t be sorry).  So we can still use TDD to our hearts content on own personal dev account.  Test, Fail, Code, Pass, and Commit.  It is a little different than the methodology we are used to, but the foundations of TDD are still intact. It still works, and in fact works well. Happy Testing!