We’re going to do that by isolating every concern in its own scope.
Run parts of the software independently.To unit and integration test our code, we need the ability to: Testing all the things, and how to get there
Of course, sometimes, the cases our software is exposed to in the wild are too many to completely test it but even then, unit testing remains a valid tool to ensure that the edge-cases that are indeed identified are handled properly. ( re-interpretation of the Martin Fowler’s UnitTest diagram ) In short, unit-testing detects issues occurring on edge-cases (ie, at the fringe of things that can happen), in a way that integration and end-to-end testing cannot. Unit-testing a piece of code on regular as well as edge-cases requires a fine control over the dependencies it uses (API clients, db connections, mailer, logger, authorization layer, router, etc.). It verifies their output and behaviour when exposed to regular cases as well as edge-cases of the inputs and dependencies (slow dependency, corrupted dependency, erroring dependency, invalid inputs, etc.).īy “dependency” we mean everything that a piece of code does not own but uses (typically, other parts of the same software like services, modules, etc.) This is testing parts of the software in isolation, controlling their inputs, and using dummy I/O systems and dependencies. Integration testing is used for regular use cases(the so-called “happy path”), because it’s usually hard to induce edge-case behaviours in real I/O systems (erroring DB connections, corrupted data, filesystem failing, network timeouts, etc). It checks that parts of the software behave as expected when exposed to real I/O systems. Integration testing is testing parts of the software in isolation, exposing them to real inputs and using real I/O systems. We’ll see how complementary these kinds of testing can be in verifying the behaviour of our code against both regular and edge cases (ie, cases at the fringe of things that can happen) Integration testing There are lots of ways to test code we’re going to focus on integration testing and unit testing. Testing code means subjecting it to controlled input to verify it produces the expected outputs, and exhibits the expected behavior. We’ll present ways to make our code composable and (re-)usable. We’ll see how testability and loose coupling techniques can make our code more maintainable. Let’s have a look at a way to design usable code. Writing quality code, harder.įor a software company relying on team work, or with code projects spanning many years, one often relevant metric of code quality is how maintainable (fixable, modifiable) and extendable (re-usable, composable) it is in other words, whether or not the code is usable from a developer perspective.
0 kommentar(er)
