Now that ToDD has been in the public arena for two months, one of the things I’m happiest about is the fact that testing in ToDD is totally flexible. Thanks to the concept of testlets, ToDD doesn’t have an opinion on the specifics of your tests - all of that logic is contained within the testlet.

I believe there’s real value in going further than simple “ping” tests when validating that your network is working as you expect. Customers aren’t pinging you - they’re using your applications. To that end, I have introduced a new testlet to the ToDD project that makes HTTP calls and reports on application-level metrics.

There are some very real advantages to testing HTTP reachability instead of settling for simple “ping” tests. In addition to verifying network connectivity, HTTP testing also ensures that the web application is also up and able to produce the desired status code. We’re also able to get some insight into performance at the application level.

In my initial presentations on ToDD, I talked about a use case for being able to “keep your SaaS providers honest” by making HTTP requests against the services you use in a distributed manner:

The new HTTP testlet fundamentally wraps curl and uses the template-able output from that utility to extract metrics like status codes, and end-to-end latency. See the example below for the full list of metrics exposed by this testlet:

There’s much more you could (and probably should) do with this HTTP testing within your own organization. For instance, while this testlet does ensure that an HTTP connection can be made, and provides insight into basic performance numbers, it is not able to do things like conduct transactions.

This is one of the greatest examples of why I chose to make testlets as flexible as possible. It’s important to go further than I did, and write your own testlet that is able to perform transactions on your organization’s web applications, to more closely mimic real-world usage. However, generic HTTP connectivity is simpler, and that’s why I’ve included that testlet within ToDD.

Naturally, all of these metrics are exported into a TSDB like InfluxDB:

Which also means we can immediately make use of this data in a visualization tool like Grafana:

This is just one step on the journey of being able to easily run application-level testing on our network infrastructure to help us gain the confidence we need to move forward with network automation! Please check out the ToDD documentation or check out the mailing list if you have any questions or run into any problems!