Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Applying Test-Driven Development in the Cloud

Applying Test-Driven Development in the Cloud

This item in japanese

In the cloud, application development can be treated end-to-end with its accompanying infrastructure. This makes it possible to use test-driven development (TDD) and refactoring on the full application, which can bring down maintenance costs.

Michal Svoboda will give a talk about test-driven development of cloud apps at XP 2023. This conference is held June 13-16 in Amsterdam, the Netherlands.

For cloud apps, applications can be developed and deployed along with their accompanying infrastructure as one coherent piece of code. According to Svoboda, removing the "infrastructure" as a separate element allows us to apply agile engineering techniques such as TDD and refactoring on the scope of the whole app, including its cloud resources.

The latency and asynchronous nature of the cloud can be a problem. Waiting for resources to provision or timeouts to elapse obstructs the rapid TDD cycle. Svoboda suggests switching to an incremental update model, i.e. to not destroy resources at the end of each test, and to have a clean deployment when integrating only:

Test speedup techniques were drawn from our TDD bag of tricks. Tactically using state-based tests or testing only modified parts of the code would be a few examples. It pays to remember that hurdles in testing provide useful feedback to the whole development cycle. This feedback made us weigh carefully our architecture and procedural choices.

According to Svoboda, TDD brings down the app maintenance costs which are by far the major part of software TCO. Using TDD, it is easy to add features or refactor anywhere, be it your own code or use of the cloud resources, even years later.

InfoQ interviewed Michal Svoboda about cloud development using TTD.

InfoQ: How has the cloud impacted the way we provision infrastructure?

Michal Svoboda: Through APIs, cloud resources can be created and destroyed in a fully automated way. (Strictly speaking, this isn’t just the cloud. Cloud providers just make this function extremely accessible.) We don’t need to think about "infrastructure", as in servers and networks that exist independently of applications. "Infrastructure" no longer requires a special approach.

On top of the classic infrastructure, the cloud provides single-specialty services, such as storage, functions, or streams. Many cloud apps don’t just run in the cloud, they consist of the cloud.

InfoQ: How do you do test-driven development for cloud applications?

Svoboda: TDD of cloud apps is similar to TDD of other apps. Instead of calling constructors and functions to create objects in memory, we call APIs to create resources in the cloud. An "arrange, act, assert" test for a stream resource is illustrated in pseudo-code below:

[Test that stream can be written and read]

  1. Deploy stream and read/write roles
  2. Put data to stream using writer role
  3. Poll stream using reader role, asserting the correct object is received or timeout
  4. Remove stream and roles

This is a very simple functional test. State-based tests can be performed using API calls that "query configuration" of resources. More complex setups of resources can be tested using the same principle.

As per TDD, we let the test be written first, fail, and follow with the implementation. Importantly, we listen to feedback and let any difficulties of testing drive our development. Our technology, architecture and procedural choices are based on ease of testing.

InfoQ: What challenges have you faced and how did you deal with them?

Svoboda: Available tooling was a problem. For this TDD on cloud approach to work well, resource deployment code must be first-class citizen in the programming language of choice. Contemporary tools provide command-line interfaces over a model in their own languages in a "cloud Makefile" fashion. Because these tools follow the "separate infrastructure" paradigm, it can get cumbersome to communicate with them. This was great feedback as well early in our development and steered our tooling and provider decisions.

InfoQ: Besides lower costs, what benefits did you get from doing TDD for cloud apps?

Svoboda: The tests make it possible to account for edge cases. The applications are stable and we know what to expect. We even worked out a few rough edges with our cloud provider!

Because our approach made it very easy to set up and test resources, we benefited in the prototyping phase as well. The cloud is a complex environment and we failed more times than I can count due to programming errors and wrong functionality assumptions. Using this approach, we failed fast.

Many important questions were pragmatically answered early in the development. What technologies will we use? How will we deploy and operate our application? How will we manage long-term state and sensitive data?

InfoQ: What’s your advice to people who want to try out TDD for their cloud application?

Svoboda: Start slow with a smaller-scale project first. There are a few things that will need bootstrapping before the first test can pass. Get used to the mechanics. Make sure to refactor aggressively. Learn from the feedback. Good luck!

About the Author

Rate this Article