Inside-Out vs. Outside-In Testing in TDD
Explore the inside-out and outside-in testing approaches within test-driven development. Understand how starting from internal components versus external user input affects software design, development speed, and code structure. Learn the strengths and weaknesses of each method to better apply TDD with hexagonal architecture principles.
We'll cover the following...
In this lesson, we’re going to review our choice of starting point for our TDD activities. The first place to look at is inside our software system, starting with details.
An inside-out approach with TDD
When starting to build software, we obviously need someplace to start.
One place to start is with some of the details. Software is made up of small interconnecting components, each of which performs a portion of the whole task. Some components come from library code. Many components are custom-made to provide the functionality our application needs.
One place to start building, then, is on the inside of this software system. Starting with an overall user story, we can imagine a small component that is likely to be of use to us. We can begin our TDD efforts around this component and see where that leads us. This is a bottom-up approach to the design, composing the whole from smaller parts.
The inside-out approach for Wordz
If we consider a simplified version of our Wordz application structure, we can illustrate the inside-out approach as follows:
The diagram shows the Score component highlighted because that’s where we’ll start development using an inside-out approach. The other software components are grayed out. We’re not designing those pieces yet. We would start with a test for some behavior we wanted the Score component to have. We would work our way outward from that starting point.
Note: ...