Why Test-Driven Development is Non-Negotiable at Aescentia
At Aescentia, testing and test-driven development isn’t just something we do because clients request it, nor is it something we do, depending on the engagement.
We test and do test-driven development because it results in agility for our customers in the most cost-effective way. Through test-driven development we complete discrete capabilities and experience fewer bugs overall; staying focused on delivering new and different capabilities — maturing them, testing assumptions iteratively. Testing ensures accountability and that developers extending or maintaining those capabilities have the confidence to do it. This mentality from the top down is core to our approach.
We’re clear in our messaging, early on, about the emphasis we place on testing, the transition to operations, and RIO — which helps customers understand our approach and for us to attract and retain employees who share those values.
Here’s a deeper look at the four pillars of our test-driven development and continuous delivery philosophy:
First Line of Defense against Regression
Code not only provides value — it comes with a burden. Any new code has an impact on an existing code base and can result in unexpected side effects. The right level of code coverage and integration testing provide the first line of defense against regression of existing features as well as metrics on readiness to deliver high-quality capabilities, continuously. Therefore testing is critical to our success and cost-effective delivery.
Ensures Rapid ROI
Test-driven development allows us to better factor code so that it is maintainable, extensible, and able to be transitioned to operations — achieving rapid return on investment for our customers. It enables us to refine and mature capabilities, leveraging fewer less expensive, but empowered, resources to support and operate those capabilities.
Documents the Intent of the Capability, Where Used, and Readiness for Delivery
I feel that commenting code is unnecessary and potentially harmful. It is a ticking time bomb. If the code is such that it requires in-line text to describe what it is doing, there’s a much bigger problem — it is not well factored, often brittle and monolithic, and as a result is or will become difficult to maintain and extend. Instead, we test first with both unit and developer integration tests. The tests not only allow for continuous automated delivery but documents the purpose of the API and how the engineer intended it to be used — its why and how.
Commenting code is not only unnecessary, but it is very likely stale and misleading. So we don’t do it. We do, however, maintain strict code and testing standards, patterns, practices, and guidance.
Together with continuous delivery and monitoring, test-driven development helps to reveal why a capability was delivered; allows us to discover where and if it is used; and to collect and report on quality, readiness for delivery, and the impact of change.
I consider this the most important reason for testing: it provides us, and our customers, the creative confidence to make, at times invasive, changes — vastly reducing the risk of harmful and unexpected side effects. We are confident in the products and capabilities we deliver. Our approach allows us to iterate, to explore new and different ways of doing things — to innovate, together.
Our aim is to be good stewards of our customer’s investment — therefore testing is non-negotiable when engaging Aescentia.
The Benefits of Testing and Test-Driven Development — At a Glance
1. First line of defense against regression of existing capabilities
2. Results in more maintainable code — enabling ROI
3. Documents the intent of the code, where used, and its readiness for promotion
4. Provides us the creative confidence to extend and mature capabilities, push boundaries, and explore new possibilities — to innovate