In Agile methodologies, testing is one of the pillars of the product-building process. Still, tests can be detrimental if not properly set. Even more so when they pile up and get in the way of developers. In this episode, Software Developer Daniel North teaches us how to simplify tests.
In like manner, he advises us how companies should conform their policies to streamline their policies and allow teams to be flexible yet without running wild.
Edited transcription
With over 30 years of experience in the software development industry, Daniel North is one of the pioneers of Agile methodologies and the DevOps framework. More importantly, he is the person behind Behavior Driven Development (BDD).
BDD is an approach to software development based on meeting user requirements as a way of ensuring product quality. In practice, BDD illustrates how users will interact with the product and builds automated tests on top of them.
Still, Daniel has moved past the concept of BDD. As of now, he defines his interests in the industry as towards organizations finding the balance between “that sense of small team autonomy and excitement and energy” and the invaluable guidance centralized decision-making provides.
Piles of tests: The issues with the testing pyramid framework
Daniel believes that the testing pyramid, while it looks good on paper, and “makes a good diagram”, isn’t always the best approach to testing. The testing pyramid framework establishes different categories of tests ordered from top to bottom: manual tests, UI tests, integration tests, and unit tests.
The lower inside the pyramid, the more automated the tests. Automation allows teams to test faster by doing so in short feedback loops. As a result, they learn sooner if their code needs fixing.
According to Daniel, the testing pyramid becomes problematic when combined with “record playback tools like Selenium” or tools that allow codifying tests into natural language “like Cucumber or SpecFlow”. In such cases, developers can end up over-indexing tests, resulting in the testing process taking longer to complete than it should.
To build a test system properly, Daniel points out it is crucial to limit the number of tests. First of all, he sees that sometimes developers made unit tests that are not such:
“A unit test has a very specific, clear definition in the testing canon, and the thing you are writing when you do TDD or BDD is not a unit test, it’s a code example, that’s going to guide your design, and it’s a model client. You’re writing a little model client, and if you’re doing it right, you’re writing a little model client for some code that doesn’t exist yet.”
This model client isn’t a test, but rather an “example to guide our design”.
Secondly, Daniel notes that developers, as they are not testers, are prone to limit how many of them they write. Developers, he says, write tests merely to guide their development tasks, so they shouldn’t be asked to dedicate too much to write them.
Thirdly, Daniel mentions that tests, instead of making it safe to change code, can deny developers from doing so:
“As soon as I change the interaction, because I want things to happen in a different order, or I change a dependency, a load of tests breaks, you get this brittleness, which should never have happened”.
Lastly, Daniel understands that more manual tests (those above in the pyramid) shouldn’t necessarily be slower than automated tests:
“If I am putting together my code, my APIs, my components in a reasonable way, and those components are reasonably small and self-contained, then I should be able to test the whole component and think of that as a unit”
Daniel blames the performance issues of the pyramid to the tooling, which he qualifies as a “painkiller”. In this regard, he recalls his experience with a client:
“They had literally thousands of, in this case, SpecFlow; they called them BDDs and they would run all the BDDs and the BDDs took many hours to run and there were thousands of them. So, I took a look at some of them, right and they’re practically copy paste, copy paste, copy paste with a few lines different.”
This kind of testing ends up slowing down production, even in cases where the code has no problem.
To solve these issues with tests, Daniel recommends simplifying. He himself uses Pytest since it allows to write tests in a simple language (Python) and get rid of redundant tests:
“not only did we now have a fraction of the assets to manage, we could get rid of hundreds of these BDDs and replace it with a few hundred lines of well-structured Python.”
Due to their simplicity, these tests run much faster. At the same time, Daniel ensures that simpler tests can also help as documentation: “more documentation isn’t better; better documentation is better.”
When regarded as documentation, testing can help to grasp where things can go wrong:
“If I can understand very quickly what I’m likely to mess up, I can manage that.”
Moreover, testing provides a secure ground for the mind of programmers:
“Somewhere in there is some activity that should give me some confidence about this application that I wouldn’t have otherwise”.
Simplify through alignments
Daniel understands the solution to working effectively is not implementing a tool or framework as a one-size-fits-all solution: “what you have now is a solution looking for a problem.”
Instead, Daniel encourages to work towards a clear idea of how does a better organization looks like, and figure out what needs to change before moving forward in implementing a solution:
“So, we think of the transformation, the product is about behavior change of your staff, your employees, and yourself, the people in the organization: What’s their target behavior? What’s the outcome here?”
After figuring out the target behavior, it is possible to start and choose a framework that fits the organization as a whole to simplify decision-making by shortening the options, or as he puts it, “you centralize the policy, but you federate the decision-making.” As such, to Daniel, it is essential to establish alignments in different terms:
- Technology alignment, to simplify architecture, design, and tooling.
- Product alignment, to simplify what teams are building.
- Leadership alignment, to have clear policies throughout the organization.
- Direction alignment, to provide all teams with unambiguous direction and objectives to focus on.
To achieve this, Daniel recommends creating a technical council of sorts, made of representatives from across the organization. They will determine the policies, document them, and share them with the teams. In this way, teams can work autonomously within what the policy allows:
“Once we’ve got that alignment, that sense of alignment, it means that any team knows it can go as fast as it likes, and it’s not going to trip over the other teams.”
This also helps the onboarding process, as new hires can adapt faster by providing a standardized way of how the organization works.
The bottom line
Daniel North has recently given talks on the topic of transformation as a product. Moreover, he recommends his talk with Anna Urbaniak, Meeting Of Mindsets for those interested in the subject of autonomy through alignment. You can reach Daniel by his email and on Twitter
