Sign In Sign Up

Sign In Sign Up

Pragmatic Testing in AdonisJS with Japa

Playing Next Lesson In

seconds

Pragmatic Testing in AdonisJS with Japa

Pragmatic Testing in AdonisJS with Japa #2.1

Naming Tests

In This Lesson

We'll discuss how to quickly write a good test name in a single, brief sentence.

Created by: @tomgobich
Published: 18 hours ago

Notes Used to Craft this Lesson

A common naming convention for tests in JavaScript is to name the test with a brief sentence outlining:

What is being tested
The scenario or condition
And, the expected outcome.

Often, you can start this silently with "it should" followed by your test name. For example, let's make a new spec called "state management."

node ace make:test state_management --suite=unit
  
    
      Copied!

Inside the group, let's add a counter variable and set it to 0.

test.group("State management", () => {
  let counter = 0;

  test("example test", async ({ assert }) => {});
});
  
    
      Copied!

What we'll be doing here is incrementing this counter as the tests run to showcase the state. So, for our first test, it should increment the counter by one. If we drop "it should", we have a perfect test name.

test("increment the counter by one", async ({ assert }) => {
  counter++;
  assert.equal(counter, 1);
});
  
    
      Copied!

Let's add another to increment it again, for which "it should" increment the counter by one again. And, we'll assert that it should be two now.

test("increment the counter by one again", async ({ assert }) => {
  counter++;
  assert.equal(counter, 2);
});
  
    
      Copied!

Perfect! Lastly, I want to note that, as good practice, it's generally recommended that each test be uniquely named. This helps reduce confusion and makes the tests easier to find.

Additionally, it's typically considered bad practice to have tests rely on other tests, as we're doing here. We'll take a look at a solution for this in the next lesson.

Join the Discussion 0 comments

robot comment bubble

Be the first to comment!

Transcript

what is being tested, the scenario or condition, and the expected outcome. Oftentimes, you can
start this with a silent, it should, followed by the actual test name. For example, let's make a
brand new spec for a state management unit test here, and we'll create some actual tests within there. So I'm going to hit Command or Control J to open up Visual Studio Code's terminal,
and we'll do node.asemaketest state management, and specify that we want this to go into the
suite unit. By adding the suite flag directly into our node.asemaketest command, this will automatically select that, and it won't prompt us for a selection as the next step. So we can
hit Enter there, and it will automatically create that, and you can see it's already picked up over here and run our example test within our state management spec. So Command or Control J to hide
that back away within Visual Studio Code, and we can jump over into our state management spec.
Within our test group, let's make a counter and set it equal to zero. This is outside the actual
test itself. So as Yoppa runs through this test group, our counter will persist throughout all
of our tests. So what we'll be doing here is incrementing this counter as the tests run to showcase state within our test group here. So within our actual test, and this serves as a
test name as well, it should increment the counter by one. So we have our it should, and then the
test name will be increment the counter by one. So our entire sentence here kind of covers all three
of our check boxes. We have what's being tested, and the entire sentence covers the scenario, condition, and expected outcome. Great. So for our actual test, we'll go ahead and increment our
counter, and we can assert, use our equal check here, the actual value, which is our counter,
and then we expect that counter to now equal one. If we give this a save, there we go. We have our
test name of increment the counter by one, and our assertion verifying that it is indeed incremented.
If we add in another test, we'll increment the counter yet again, so it should increment the
counter by one again. Async, assert, get our callback, counter plus plus, and we can now assert
that we expect this to equal counter as the actual value. And since we start at zero, this
test increments it by one, and nothing's resetting the counter in between, we would then expect this
to be two whenever it reaches this test. If we give this a save, we can verify that is indeed true with our assertion. For right now, these test names are rather basic, but we have a ton more lessons
that will help hammer this point home, and through almost all of them, we will use the same it should
followed by the test name that we end up using to describe what our test is doing, the scenario we're testing within, and what we expect to be the outcome of the test.

Pragmatic Testing in AdonisJS with Japa

7 Lessons

38m 40s

The Foundations

1

Japa Fundamentals

2

Stop losing your best ideas!

Use our integrated note feature to capture and organize your key insights. Take a note at any timestamp and jump instantly back to that moment in the video with a single click.

Sign up Sign in