SaaS
Test first, then code, on a SaaS platform
In test-driven development (TDD), you first write a test that fails, then the code that passes it, and finally you improve the code. This way every feature of a SaaS platform has its check from the start. Most tests are small and fast, while a few check the whole in the browser.
A SaaS platform changes all the time: new features, new roles, new customers. Without automatic checks, every change leaves the question of whether something that worked is now broken. For every feature, we write the test first and the code second. This way the check is not a last step that can be skipped. It is the point where the work starts.
What is test-driven development?
Test-driven development, known as TDD, is a method where the test is written before the code it checks. Martin Fowler describes it in three steps. You write a test for the next feature, you write the code until it passes, and you improve both the new and the old code so that it is well structured.
The three steps repeat in a cycle known as red-green-refactor: the test fails (red), it passes (green), and the code is tidied up (refactor). Fowler adds that before the cycle starts, you write a list of the cases that must be checked, and you work on one at a time. The method is not specific to platforms, but it pays off more on them, because they live for many years and keep changing.
Why is the test written first?
The test is written first because that proves it can fail. A test written after the code often passes on the first run, and nobody knows whether it would ever catch a mistake. When we see it fail first, we know it really checks something.
There is a second benefit. To write the test, the feature has to be described exactly: what it accepts, what it returns, what happens when something goes wrong. This shows early what is missing from the requirements, when fixing it costs a question and not a restructuring. That is why the method fits with the requirements analysis done before the code.
Which tests are needed, and how many?
You need many small tests and a few large ones. This is the idea of the test pyramid, as Fowler puts it: many more low-level tests than tests that go through the screen. In the middle sits a layer of tests that check the application through its service layer.
Level | What it checks | How many |
|---|---|---|
Small tests | One rule or one calculation, on its own | Most of them |
Service tests | One feature through the application's service layer | A moderate number |
Screen tests | A full user journey in the browser | The fewest |
Fowler explains why screen tests should be few: they are brittle, expensive to write and slow to run. He also notes an exception. If the high-level tests are fast, reliable and cheap to change, then the low-level ones are not needed. In practice, few tests reproduce real use, and the small ones do most of the work.
How do we work on a platform?
We follow the same order for every feature. The order is short and always kept:
The requirement is written and approved. Every feature comes from the written requirements of the first stage.
The test is written and it fails. We check that it fails for the right reason.
The code is written until the test passes. Nothing is written that no test asks for.
The code is tidied up. After every change, the tests run again.
The feature is checked in the browser. We open it as a user and compare it with the approved design.
Each stage moves on only when all checks pass. Our tool Planner applies this order when it builds an application from a written specification, and we describe it in the Planner case study. What matters is that the tests are not loosened to make them pass: if a check fails, the code is fixed.
What does a test look like in practice?
A test is a sentence from the requirements, written so that a program can check it. If the permissions table says an operator does not approve requests, the test starts as an operator, tries to approve a request and expects a refusal. Before the code is written, the test fails, because the refusal does not exist yet.
Then the code that refuses the approval is written, and the test passes. If someone later changes the rule by mistake, the same test fails right away, before the change reaches users. This way the requirements you approved stay active after delivery, and not only on paper.
What happens when a bug is found?
When a bug is found, a test that reproduces it is written first. The test fails before the fix and passes after it. This way the same mistake cannot come back without a check catching it, and every fix leaves permanent protection behind.
This also applies to what the team of agents finds when it examines the finished project for bugs, usability and security. Every confirmed finding is fixed in the same way. We explain the process in the case study on quality and security agents. A good example is the security of permissions, which we describe in the article on roles and permissions in a SaaS.
Frequently asked questions: Test first, then code, on a SaaS platform
Does TDD make the project slower?
At the start, each feature takes a little more time, because its check is written too. That time is saved later, when changes are checked automatically and not by hand. On a platform that will keep changing for years, the gain is clear.
Does every platform need tests?
The more complex and long-lived a platform is, the more it needs them. A small internal tool can do with less dense checking. Exactly how much is agreed in the requirements and written into the project scope.
Do automatic tests replace checking by a person?
No. Automatic tests catch the mistakes that can be described in advance. That is why we also check in the browser, as users, and we try the result on real scenarios from your daily work. The two complete each other.
What does it mean that all checks passed?
It means that no test fails and that the feature has also been tried in the browser. Only then do we move to the next step, so that a mistake is not carried forward. What exactly the delivery includes is written in the project scope that you approve at the start.
Do you want a platform that is checked from the start?
If you are planning a SaaS product or an internal platform and want to know how each feature will be checked, describe your project in the project request. We will discuss the tests together at the requirements stage. See also the page on SaaS platforms.