- [Presenter] While there are many different ways
to write test specifications,
testing frameworks provide consistent interfaces
for developers.
Most frameworks provide multiple domain specific languages
or DSLs for writing tests.
Each standardizes the vocabulary used to write tests,
which in turn improves developer communication.
Each DSL describes how to interact with a framework.
Common examples include, test-driven development or TDD,
and behavior-driven development known as BDD.
Those terms may be familiar, but what do they mean?
Test-driven development is a software development process,
in its purest form, software requirements
are turned into test cases,
then the software is improved until those tests pass.
Throughout development,
the tests are run over and over again,
giving feedback to the programmer.
Strictly following test-driven development
in its most academic form
can be too extreme for most situations.
Outside of some very specific corporate
or technical environments,
you probably won't know all of the tests
that you need to write before building your software.
The more important goal is to have a feedback loop
to inform the developer,
that's the goal of behavior-driven development.
So, what are the differences between test-driven development
and behavior-driven development?
Believe it or not, technically they're the same,
the difference is around the vocabulary used
and the philosophical approach.
In test-driven development,
the terminology used is about testing,
including tests and test suites.
This leads developers to describe
when something works and when it doesn't.
The problem is that it can be too literal,
which can lead to fragile, overly specific tests.
To address this,
behavior-driven development uses terminology
about behavior examples
This way, developers describe
how and why something works with concrete examples.
Dan North, who published the concept
in a writing titled, "Introducing BDD"
Said in the introduction,
"I decided it must be possible to present TDD
in a way that gets straight to the good stuff
and avoids all the pitfalls."
So, what's this approach?
The acceptance criteria for a test
are presented as a scenario with a common structure.
Given some initial context, when an event occurs,
then ensure some outcomes.
By using this kind of language,
it frames the testing task
as a description of how the system works.
Using the example of reservation creation,
here's how a BDD scenario would read,
the scenario is that a reservation
should be created with a valid email.
So, using the acceptance criteria structure,
given a submitted email, and that the email is valid
when the reservation is created,
then ensure that the reservation was created successfully,
and that the reservation email is what was submitted.
When writing unit and integration tests
with a BDD style interface,
the commands used reflect the intent.
Starting with describe,
which is sometimes aliased as context,
you can create a group of specifications.
The specification itself, is created with it or specify,
which creates the test case itself.
Often, a specification is also known as a spec
or a test spec.
There is additional commands around the setup
and Teardown of tests.
Before, and the logical equivalent of after,
provide customization of the setup
and Teardown of a group.
If something needs to happen more often,
beforeEach and afterEach customize the setup
and tear down for every specification in a group.
How does this look when testing a reservation creation?
Here's the code example.
We'll start by describing the group of specifications,
which is the reservation creation.
Then in natural language,
it should need a reservation with a valid email.
This spec describes the intent to another engineer
and also gives an example if they want to create an account.
Given the context of an email,
when a reservation is created,
expect that the reservation has a properly named email
and the value should be equal to the email provided.
The nice thing about this approach,
is that it describes the intent and how,
briefly and accurately.
Let's review.
Testing frameworks provide interfaces
to create test specifications.
Each interfaces uses a standard known as a DSL
or domain specific language for consistency.
Some of the more common are, test-driven development or TDD
and behavior-driven development, BDD.
They are technically the same,
but the vocabulary and approach of BDD
describes the how and why.
Now that we have a better understanding
of how tests are structured,
how can you verify
that the results of an execution are correct?