Most code is not written and designed with testability in mind. Our complex systems are hard to test. We then test them partially, and send them off to production, where we find out how they actually behave. If we put some effort in the beginning, we'll be able to test better, deeper and cheaper. We won't drop tests because they are too expensive, or take too much time. We'll have more information on how our app runs before it ends up in the users' hands.
This tutorial is about things we can decide and do in the code, design, and test levels, to know more and early. These decisions open options that we can exploit later, as part of our testing. We'll start with testability patterns at the code level, that make it easier to test in different ways. Can we check application state programmatically, or just by reading very long logs? Can we mock a service call, or are we vulnerable to connectivity? We will refactor untestable code, based on design patterns to make it testable. But code level is not enough.
We can check the same behavior in different ways (from unit to API to UI). The difference is in setup, duration, and fragility costs. If we're checking domain rule logic, do we really need to login first? Can we run with a full setup database, or do we need to start from scratch every time? How does that impact our testing?
We'll consider different options for test design, and how to select the right option. We'll discuss different design aspects for testing the behavior we want, and how to these options can be set at the code and configuration level. At the API and system level, we'll discuss how the tests can run, what they can see and check. Can we setup concurrent calls to see if they are handled in an orderly fashion? Can we see the impact of a slow database connection? We'll see how observability, including DevOps collected information, fits into our testing strategy. We'll see how it can inform our knowledge on the system.
This tutorial is targeted for both developers and testers, who want to make sure their code works, and can actually prove it. As testability is baked in, observability is built around it and the right test design is selected, we can achieve more information about our system, early on, and at an affordable cost.
