Tested code

To write quality code we rely on testing, which for us means unit tests, integration tests, TDD and BDD. As developers, we know that tested code benefits everyone: the client gets exactly what they want, a working, verifiable product.

We don't test everything by default: testing adds development time and therefore cost. During the initial project analysis, together with the client, we try to answer two questions: "How much could the application change in the coming months?" "Where is a bug simply not acceptable?" The answers tell us which parts of the code need tests.

• It shows in advance which part of the code broke during new development, so we can fix it before release.
• Flows and interactions are verified in minutes, not in hours of manual testing, which is always error-prone due to simple oversights.
• It is real documentation of the code, with no need for long, verbose docs.
• It makes long-term maintenance possible: it only takes a few weeks to "lose the thread", and tests let us retrace the path we took.
• New developers can join a project already underway without fear of "breaking everything".
• A client can switch teams entirely without the risk of having to "rewrite everything".

Unit test

Unit testing verifies that individual classes or class methods work correctly. It should never cross class boundaries: it works in complete isolation and gives the developer solid proof that a piece of code works as intended.

Integration test

Integration tests catch the problems that arise when two units combine to deliver a more complex feature. Essentially, they check each object's inputs and outputs, making sure objects can talk to each other.

Test Driven Development

TDD is one of the practices recommended by XP (Extreme Programming), along with pair programming and others. Its mantra, red, green, refactor, describes an iterative cycle: decide what you want to achieve, write a test, watch it fail, write the code to make it pass, refactor, and start again.

In general, the value of tests lies in greater confidence when refactoring, and therefore more maintainable code. TDD amplifies this value because it forces us to think about interfaces first and implementation only afterwards, leading to better architecture.

Behaviour Driven Development

BDD is an extension of TDD that emerged (outside the agile context of XP) to answer the question: TDD is great, but what should I actually test? The answer lies in the keyword "behavior", meaning behavior the client can verify too. Technically, BDD isn't very different from TDD; it's more of a philosophy that lets developers and management communicate with a shared vocabulary focused on what truly creates value for the client's business. It starts from what the client sees, as described in user stories, which are in effect the first, outermost test of a given feature.