Resources
Software quality and testing
An automated test turns an intention into a permanent guarantee. It fixes the expected behaviour, checks it on every change, and makes it possible to revisit code written six months earlier with confidence.
What a test makes possible
Writing a test before the fix turns a symptom into a verifiable fact: the test fails, the cause is identified, the fix makes it pass, and the guarantee stays acquired for good. That is what lets a rotating team pick up code without its author. Version control keeps the history of every decision, code review circulates knowledge, and continuous integration replays the whole suite on every change.
- A test that fails first: it proves the cause is really that one
- One unit test per business rule, fast and isolated
- One integration test per complete user journey
- One code review per change, before merging
- Continuous integration replaying everything, on every push
The four practices that reinforce each other
Version control
Every change carries its intent and its author. Finding out why a line exists becomes a one-minute question.
Code review
A second pair of eyes before merging. It spreads conventions far more effectively than a rulebook.
Design patterns
Named solutions to recurring problems. The shared name shortens the architecture conversation.
Layered architecture
Business logic separated from infrastructure. Changing database then stops being a whole project.
The programme that carries these practices
Software engineering and deployment occupy whole blocks, each with its own hour count. The table gives the real weight of every subject in the programme.
| Teaching block | Year | Hours | Credits |
|---|---|---|---|
| Web foundations | 1 | 200 h | 20 |
| JavaScript and TypeScript | 1 | 220 h | 22 |
| Programming interfaces and data | 1 | 160 h | 16 |
| React applications and mobile development | 2 | 240 h | 24 |
| Deployment | 2 | 140 h | 14 |
| Cross-curricular base | 1-2 | 120 h | 12 |
| Project and placement | 2 | 120 h | 12 |
Questions about testing
How many tests should I write?
As many as there are business rules, plus one per complete user journey. The right measure is this: after a change, the test suite is enough to decide whether the software ships.
Do tests slow development down?
They move the time: a few minutes when writing, against hours of diagnosis avoided at every revisit. On software maintained longer than three months, the balance reads very quickly in favour of testing.
What place does code review hold in assessment?
It is an assessed skill in its own right: you review a peer's work with the official grid, and the quality of your review counts towards validating the block. Reviewing teaches as much as producing.
Explore next
- An SME websiteBuilding a small company website: purpose, structure, copywriting, publication, domain name, certificate, search visibility and audience measurement.
- Mobile applicationsCross-platform mobile development: single codebase, offline operation, synchronisation, store publication and version tracking.
- Designing an interfaceUser research, information architecture, visual hierarchy, component states and usability testing: the interface design method.
- Digital accessibilityContrast, keyboard navigation, screen readers, low bandwidth: accessibility checks and how to fold them into everyday work.
- Component systemsDesign tokens, component libraries, documentation and hand-off to development: building an interface system that holds at scale.
- Writing for the webWeb writing techniques: information first, headings that answer, short sentences, the words readers use, clear calls to action.