How can software evolve without breaking what worked yesterday?
At CoreFactor, we approach this question at several levels. Because a correct calculation is not enough to make software work.
Pierre Bony
President, co-founder and CTO
A new feature arrives. Cool!
But does the appointment schedule still work? Are billing calculations still correct? Can we still create a client and link their animal to them?
In our last #TechNote, we explained the journey a release takes before deployment. At the start of that pipeline: automated tests. But what do they actually check?
First, checking the details that matter.
Take an invoice line: a quantity, a price, a discount, and VAT.
We check the expected results, but also less obvious cases: a fractional quantity, rounding, a 100% discount, or inconsistent amounts that must be rejected.
These are unit tests: they isolate a specific rule and check that it produces the expected result. Not an approximation.
Next, checking that components work together.
A rule can work on its own and cause problems when it interacts with the rest of the software.
This is the role of our integration tests: we recreate a real VetCoreSolution® environment in isolated containers, with the same server components, real databases, and test data.
We then check how this whole system works. We also measure certain operations on volumes representing years of software use, including loading appointments, clients, animals, and consultation histories.
Because software used in an empty practice does not tell the same story as software with 15 years of activity.
Then, using the software as in a veterinary practice.
- An automated browser opens the interface.
- It creates clients.
- It links animals to them.
- It books appointments.
- And it checks that these appointments appear in the schedule, for the right clients.
These are end-to-end tests: we no longer check just a function or an exchange between servers, but a complete journey through the software.
And when things do not go as planned?
We also deliberately simulate failures, such as a server error when creating an animal.
Software must work when everything goes well. But its reaction when an operation fails also deserves to be tested.
The challenge: avoiding starting from scratch with every change.
We also retain scenarios that reproduce bugs we have encountered before. They allow us to check that a change does not reintroduce a previously fixed problem: these are known as regression tests.
These checks are part of the pipeline presented in the previous episode: changes automatically trigger tests, and a failed check blocks their integration into the main codebase.
Does this guarantee software without any bugs? No.
A test checks a planned scenario. It cannot anticipate every situation, nor replace validation by domain experts and feedback from the field.
But the goal is not only to check that the new feature works.
#TechNote #VetCoreSolution #SoftwareQuality #AutomatedTesting #SoftwareArchitecture #VetTech #VeterinarySoftware
