4.5Automated tests & quality
The essentials in 30 seconds
- Three levels of verification: unit tests (does a procedure or class give the right result? — the most profitable because it targets a business rule), interface tests (replay a recorded scenario: open, enter, validate, verify) and the project audit.
- The main interest of automated tests is not finding bugs today but detecting REGRESSIONS tomorrow: retesting the whole application by hand is impossible, so we do not do it — and regressions reach production.
- Best practices: start with the business core (calculations, critical rules), test edge cases (zero, empty values, year changes), write a test for each fixed bug — and keep tests up to date, because ignored obsolete tests are worse than no tests.
Mini-case thread — Yacine secures his trading calculations
Yacine, a WinDev developer at an electrical equipment trading SME in Oran, has just fixed a bug in the discount calculation: a customer noticed it three months later on their invoicing. He decides never again to settle for 'it seems to work'. He first writes unit tests on the business core: VAT calculation on the electrical catalog, discounts, due dates. He systematically tests edge cases — zero rates, negative amounts, year-change dates — because that is where bugs hide. He then records a few interface scenarios on the critical path (entering an order from start to finish) to detect regressions. And he sets himself a rule: for each fixed bug, he writes a test that reproduces it, so that it never comes back. He notes the real benefit, the most underestimated one: the confidence to modify the code without fear. He completes this with code review and user feedback: quality goes beyond tests.
Standalone case for this section: it returns in the course, the diagram, the script and the 48h challenge of section 4.5.
1. Three levels of verification
The quality of an application cannot be decreed: it is built and verified. WinDev distinguishes several approaches. (1) Unit tests: verify that a procedure or a class gives the right result for given inputs (does the VAT calculation return the right value? and for a zero rate? and for a negative amount?). This is the most profitable test, because it precisely targets a business rule. (2) Interface (UI) tests: automatically replay a usage scenario (open a window, enter, validate, check the result) — WinDev lets you record these scenarios. (3) The project audit and analysis tools, which report anomalies and improvement points.
2. Automated tests change everything
Why do automated tests change everything? Because they are replayable at will. Their main benefit is not finding bugs today, but detecting regressions tomorrow: when you change a rule or fix a defect, how do you know you have not broken anything elsewhere? Retesting the whole application manually is impossible in practice — so we do not do it, and regressions reach production. Automated tests do this work in a few minutes. It is also, often underestimated, the confidence to modify the code: without tests you pile up patches, with tests you refactor serenely.
3. Best practices & quality in the broad sense
A few best practices. (1) Start with the business core (calculations, critical rules) rather than aiming for total coverage. (2) Test edge cases (zero, empty values, extreme values, year-change dates): that is where bugs hide. (3) Write a test for each fixed bug to guarantee it will not come back. (4) Keep tests up to date: obsolete tests that are ignored are worse than no tests. Finally, quality goes beyond tests: code review, documentation, conventions and user feedback are part of it too.
🔎 Concrete example — 🔎 Concrete example — A unit test and its edge cases
Target a business rule, as Yacine does:
// Test unitaire du calcul de TVA du catalogue electrique
PROCEDURE Test_TVA()
sTTC est un numerique = CalculeTTC(1000, 19)
SI sTTC <> 1190 ALORS
Erreur("TVA attendue 1190, obtenue : " + sTTC)
FIN
// Cas limites : taux a zero et montant negatif
SI CalculeTTC(0, 19) <> 0 ALORS
Erreur("Cas limite zero non gere")
FINReading: a unit test verifies a procedure for given inputs, including the edge cases where bugs hide.
Lesson: this test becomes the guardrail that detects a regression if the rule is modified later.
Section vocabulary
- Unit test
- Verify that a procedure or class gives the right result for given inputs — the most profitable test, because it targets a business rule.
Simple example: Yacine tests the VAT calculation of the electrical catalog.
What it is not: clicking manually in the interface to 'see if it works'.
Reflex: verify a rule → the unit test.
- Interface (UI) test
- Automatically replay a usage scenario (open, enter, validate, verify); WinDev lets you record these scenarios.
Simple example: Yacine records entering an order from start to finish.
What it is not: a test that only checks isolated calculations.
Reflex: replay a path → the interface scenario.
- Regression
- A defect introduced by a modification into a part that used to work — the main risk in maintenance, and the reason automated tests exist.
Simple example: Yacine's discount fix must not break the totals.
What it is not: a bug present since the first version.
Reflex: protect what exists → against regressions.
- Edge cases
- Zero, empty values, extreme values, year changes, very long strings, special characters: where most bugs hide.
Simple example: Yacine tests a 0% discount and a negative amount.
What it is not: testing only 'normal', round values.
Reflex: find the bugs → test edge cases.
- Quality in the broad sense
- Beyond tests: code review, documentation, team conventions and user feedback are also part of the quality approach.
Simple example: Yacine has his code reviewed and notes the salespeople's feedback.
What it is not: believing that tests alone are enough for quality.
Reflex: complete approach → quality in the broad sense.
In practice — In practice — Set up tests
- Start with unit tests on the business core: calculations and critical rules (VAT, discounts, due dates) — the best effort/benefit ratio, like Yacine.
- Systematically test edge cases: zero, empty values, negative amounts, year-change dates, very long strings.
- Record a few interface scenarios on the most critical paths (entering an order from start to finish) to detect regressions.
- For each fixed bug, write a test that reproduces it: you guarantee it will never come back. And keep your tests up to date.
Step-by-step script — test like Yacine (5 min)
1) Identify the business core of your application (calculations, critical rules). 2) Write one unit test per rule (VAT, discounts, due dates) that checks a known result. 3) Add edge cases: zero, empty values, negative amount, year change. 4) Record an interface scenario on the order entry path. 5) For each fixed bug, add a test that reproduces it. 6) Run the test suite after each modification and keep it up to date.
Be targeted: the business core and edge cases bring the most; keep tests up to date, otherwise they give a false sense of security.
Copy-paste template — my tests sheet
Unitaires : une procedure/classe -> bon resultat (coeur metier)
Interface : rejouer un scenario enregistre (ouvrir, saisir, valider)
Regressions: LE risque en maintenance -> detectees en minutes
Cas limites: zero, vide, negatif, changement d'annee
Regle d'or : un test a CHAQUE bug corrige
Tenue : tests obsoletes ignores = pires que pas de tests
Au-dela : revue de code, documentation, conventions, retours usersVAT unit test
Yacine checks that CalculeTTC(1000, 19) returns 1190.
Edge case
Yacine tests a 0% discount, a negative amount and a year change.
Interface scenario
Yacine records the complete entry of an order to replay it.
Test after fix
Yacine writes a test reproducing the discount bug so that it never comes back.
✓ Best practices
- Start with the business core, not total coverage.
- Test edge cases and write a test for each fixed bug.
- Keep tests up to date and complete them with code review.
✗ Common pitfalls
- Aiming for 100% coverage on a small application.
- Leaving obsolete tests that everyone ignores.
- Believing that testing the display verifies the calculations.
Key takeaways
- Three levels: unit tests (profitable), interface scenarios, project audit.
- The purpose of automated tests is to detect regressions, not only today's bugs.
- Best practices: business core, edge cases, one test per fixed bug.
- ⚠️ Keep tests up to date; quality includes code review, documentation and user feedback.
48h challenge — apply it tomorrow
Like Yacine, choose a business rule from your application (a VAT, discount or due-date calculation) and write at least three unit tests: one 'normal' case and two edge cases (zero, negative value, year change). Then record an interface scenario on a critical path. Take the last fixed bug and write the test that reproduces it. Run the suite and note the time saved: these few minutes replace an impossible manual review.
- I write unit tests targeted at the business core.
- I test edge cases and record interface scenarios.
- I add a test for each fixed bug and keep my tests up to date.
Frequently asked questions
Are automated tests worth the investment on a small project?
Yes, but in a targeted way: do not try to test everything, focus on the business core (calculations and critical rules) and on bugs already encountered. A few well-chosen tests bring a lot; exhaustive coverage would cost more than it brings on a small project. A management application lives a long time and evolves: the real cost is not writing the test, it is not having it when a modification silently breaks a calculation and a customer notices three months later. Tests also give the confidence to modify and serve as documentation.
How do you know if your application is of good quality?
By looking at several objective dimensions: it does what it must (correctness), it withstands the unexpected (robustness), it is usable efficiently (ergonomics), it remains fast on real volumes (performance) and it can evolve without pain (maintainability) — all validated by real users. Correctness is the most important: in management, a wrong total or inconsistent stock are serious defects, all the more dangerous because they cause no visible error. Complete this with security and deployability, and listen to warning signals (fear of modifying, recurring bugs, regressions).
What is the main interest of automated tests?