We develop our code with a 95% coverage test to guarantee quality and robustness.
We rely on tests to make quality code—in our case, Unit tests, Integration tests, TDD and BDD. As developers, we are completely aware that tested code yields benefits to all parties: the client will have what it wants, that is, a working and verifiable product. Take a look at our blog to read the in-depth analyses we’ve written on testing practices.
Our approach
Testing is a practice that increases development time and thus costs so we don’t test everything regardless. In the beginning stages of project analysis, we try to answer these two questions together with our client: “How much might the application change in the next few months?” “What are the places where a bug is not acceptable?” The answers to these questions show us in what parts of the code we should implement tests.
The advantages of a test suite
- Enables us to know in advance what part of the code has been compromised during a new development, being able to * intervene before publication.
- The flows and interactions are verified in just a few minutes and not after hours of human testing which is always * fallible due to banal oversights.
- This is a true documentation of the code without the need to write extensive, verbose documentation.
- It allows maintenance over time: only a few weeks are necessary to “lose the thread of the discussion”; having * tests allows us to reconstruct the path taken.
- It allows new developers to join the project midstream without fear of “breaking everything”.
- It permits one client to completely change teams, without running the risk of having to “rewrite everything”
What tests we use
Unit test
The purpose of Unit Testing is to verify the correct functioning of single classes or class methods. It should never exceed the bounds of the class, working in complete isolation and returning to the programmer certain proof that a piece of code works correctly.
Integration test
Integration Tests enable us to identify problems which occur when two units are combined to achieve more complex functionality. Basically, the input and output interfaces of each object are verified, ensuring that the objects can talk to each other.
Test Driven Development
TDD is one of the practices recommended by XP (Extreme Programming) just like pair programming, etc. Its mantra — red, green refactor — represents an iterative process in which you decide what you want too achieve, you write a test, you see it fail, you write the code to make it pass, you do refactoring and then repeat.
In general, the value of the tests is realized with greater confidence in refactoring, thus resulting in better maintainability of the code; the TDD increases this value because it forces us to first think of the interfaces and only think of implementation afterwards, enabling us to achieve better architecture.
Behaviour Driven Development
BDD is an extension of TDD which was born (outside the agile context of XP) to answer the question: TDD is nice, but effectively what should I test? The answer is found in the key word BEHAVIOR, understood as behavior verifiable by the client. In fact, technically, BDD is not very different from TDD; it’s more of a philosophical approach that enables developers and management to communicate with each other, with a shared lexicon that focuses on that which really has value for the client’s business. We start from that which the clients see and which is described in the user stories which, in fact, are the first more external tests of a certain functionality.