Let’s consider a few ways you can do TDD for the cloud. The availability of each of these methods may be different for each package, but these general descriptions should help you to know what to look for as you choose the tools you want to work with.
Embedded servers: Check if the libraries you are using have Maven plugins that will automatically start and stop embedded virtual servers for you. Cassandra is an example of a noSQL project with excellent Maven plugins available. This is perhaps the ideal solution, because you can “spin up” a new server for each unit test and populate it with only the minimum data you need to test your functionality. One possible downside to be aware of is that the overhead associated with starting up and shutting down these embedded servers may slow down your unit tests.
xUnit-based libraries: There may be an xUnit-style library already written for the tools you are using. For example, there is an MRUnit library for writing tests of Hadoop MapReduce jobs. In the case of MRUnit, there is no real Hadoop cluster behind it, but the library essentially provides a mocked interface that you can test against. This is more efficient than spinning up actual embedded servers, but keep in mind that it may limit the usefulness of your tests.
Mock the interfaces: If no xUnit library exists for your toolset, consider mocking the behavior yourself using existing tools like JMock. This can be a simple way to at least test that you are providing the expected information to your cloud toolset’s interfaces. But, keep in mind that you may only end up reaffirming your own assumptions about what that toolset will do with your inputs, since you are only testing against your own mocks.
Call a local testing cluster: If all else fails, your team may need to maintain a local cluster specifically for running development and continuous-integration tests against. This is the least desirable solution, since a shared testing cluster may introduce version control problems between developers. Each developer could also run his own local copy of the tools on his computer, which removes the shared dependency problem. But, it is still harder to maintain than the previously described solutions that are designed to smoothly integrate into the test-driven paradigm. So, you will have to be more diligent about maintaining test-driven practices when you operate outside that paradigm.
One simple way to figure out the best TDD practices for the open source project you are working with is to see what committers to that project are required to do. Download the project’s source, and check out how they are writing their tests. You can often base your tests on their examples. Make sure you are looking at examples from the same version as you are working with, since the TDD methods available in the project may change over time.