Taking a TDD approach (Test Driven Development) to building automation. When building your application deployment you define in comments what the deployment should do. Write a simple test and expect it to fail at first (because you didn’t build it yet). Once the tests pass, we know things work on a cursory level and can now re-factor and test by deploying to different environments, etc.
When programming a deployment, say a JBoss application that has a web and wsdl interface and some other stuff.. We’ll define (in any language we want):
Let’s say, this provides the base functionality of your deployment, and later you want to add a new role / component to your deployment, like a ruby application. You can now add more and more tests to continue to define the requirements of your deployment and allow these tests to drive how it is engineered.
Some simple advise to help keep this type of approach clean:
- Keep your tests small and simple.
- Ensure test failure captures all valid output.
- Treat the test code just like production code.
- Separate your common setup and tear-down logic as much as possible.