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.

Code writing