- Now we'll dive deeper into the left side of the quadrants.
The quadrant one and two tests.
These are tests that are written before or during coding,
and they help us build the right thing.
First, let's look at a case study
that we would like to use for some examples
to illustrate these quadrant tests.
Let's pretend we're a delivery team and we're working
with the Positively Perfect Pet Salon,
that's our example project for this course.
They want some new features for their web application.
Here's what the salon has in mind.
As we go through the quadrants, we're gonna give examples
of how we apply tests in different quadrants
to these features as we develop them.
Let's talk about quadrant one tests:
the technology-facing tests that guide development.
Once again, these numbers
we've assigned the quadrants are arbitrary.
If you're building a web or mobile application,
you're probably gonna start in quadrant two.
For example, you might start drawing paper mock-ups
and testing with those.
So, different types of applications and products
will start in different quadrants.
Once we start writing the code,
we're doing quadrant one tests.
Now let's talk about some of those tests
that we do in quadrant one.
These tests help design the code.
They're focused on internal quality,
and that's what allows us to have our sustainable pace
and fearlessly change our code
as we need to add new features.
In agile development,
most teams use test-driven development.
They write a small test,
or some small, tiny, increment of functionality,
write the code that makes that test pass,
and keep iterating over that
until that particular story is complete.
We wanna make sure all these different small,
incremental components we have created work together.
So, developers write component tests.
And this is the verifying the architecture of our system.
Making sure that everything works together correctly.
For our pet salon, an example of a unit test might be
making sure that the dates entered to book an appointment
are in a valid format.
And that unit test will influence
how we decide to do our date format and our date creation.
What do we do with these kind of quadrant one tests?
Again, we're talking about internal quality.
These tests are the strong foundation
for the higher level tests that we're going to do
in other products.
It helps us write robust and maintainable code
that's easy to test.
Make it easy to automate the tests.
Provides a safety net for refactoring,
so we can change the code and if we break something,
our tests will tell us.
And we get this fast feedback about regression failures
from our continuous integration.
Quadrant one tests become the foundation
for our other testing, that give us confidence
to release our software product.
And they become part of the regression suite, again,
that lets us fearlessly change our code going forward.
Without these tests, it's really gonna be hard to succeed
in all the other quadrants.
So we urge you, when you're starting with test automation,
to start with quadrant one tests.
Now let's move on to quadrant two.
We often start our testing and our test automation
in quadrant two, and we get the whole team involved,
both on the business side and the technical side.
Let's talk about some of those.
In quadrant two, we're also doing test-first coding,
but from the business perspective.
So we're asking questions, we're getting examples
from the business of how something should behave.
We're maybe drawing paper prototypes.
We're writing the test first
so that the developers know what to code.
We have enough information
to start writing code with confidence.
If we're doing a mobile or a web application,
something with a user interface,
we'll want wire frames or mock-ups
that show us the page layout, the arrangement of content,
all the different elements of EUI, how we're gonna navigate.
And again, we can just test this with paper first,
and make quicker decisions
before we start spending time writing code.
And we do similar activities
for the non-user interface features,
like the API or doing batch processes or data warehouse.
We can always talk about these things
before we would actually write the code.
So, in the case of our pet salon,
we asked Sally the salon owner,
what's the business problem that you want to solve
with these new features in your web application?
And what she wants is to save the time they spend
answering the phone to book appointments.
So, big interruption, it takes a lot of time.
They want to get away from that manually scheduling,
and they want clients to be able to use the application
to schedule their own appointments and get confirmation.
And so we sit down with Sally, and maybe other people
at the pet salon, and start drawing on a whiteboard
or drawing on paper prototypes to work through examples.
What's the purpose of quadrant two tests.
We're talking about external quality.
How the business defines quality.
They accept this criteria that they set out
for each feature and each story.
We're talking with them about the business problems
that they are trying to solve, and helping them with those.
Quadrant two is really where agile development
is different from other types of development.
So rather than working with written requirements,
we're specifying executable tests
that will tell us what code to write.
We're capturing examples and turning them into tests.
And we're building that shared understanding.
Everyone on our business team, everyone on our delivery team
knows how each feature should behave,
and we have enough information to start coding
and building the right thing.
And we wanna focus on collaboration.
We'll talk later in the course
about different ways to have conversations
and involve the right people
to get this shared understanding.