Sign In Sign Up

Sign In Sign Up

Pragmatic Testing in AdonisJS with Japa

Pragmatic Testing in AdonisJS with Japa

Pragmatic Testing in AdonisJS with Japa #1.3

Running Tests with the Test Runner

In This Lesson

We'll learn about the various ways we can use the Ace CLI and Japa's test runner to execute all, some, or individual tests.

Created by: @tomgobich
Published: 4 hours ago

Notes Used to Craft This Lesson

When we ran node ace test, what the Ace CLI did was run Japa's test runner. As the name implies, this is what actually finds and runs our tests.

As the tests are run, it'll then print this output to us on a per-test basis, then give us a summary of all tests at the end, detailing the number that passed and the number that failed.

We can take this a step further, though, and tell the test runner specific things to run.

For example, if we just want to run a specific suite, we can do:

node ace test -- unit
  
    
      Copied!

We can run specific spec files with:

node ace test --files=tests/unit/assertions.spec.ts
  
    
      Copied!

And, even specific tests with:

node ace test --tests="my first test"
  
    
      Copied!

We can even have it rerun tests automatically using the watch flag

node ace test --watch
  
    
      Copied!

And tests will automatically be re-run as we save our files.

VS Code Japa Extension

If you're working in VS Code, there is also a dedicated Japa Extension that adds several superpowers to your text editor as well! This includes the ability to run tests with convenient buttons and a dedicated test explorer as well.

Join the Discussion 0 comments

robot comment bubble

Be the first to comment!

Transcript

runner. As the name implies, the Japa test runner is what's in charge of actually finding and running the tests inside of our project.
As the tests run, they'll then print this output on a per-test basis, then give us a summary of all tests at the end, detailing the number that passed, the number that failed,
if there were any, and vice versa, as well as how long the entire test runner took to run all of the tests. If we were to change our test's name, that would be reflected directly as well.
So right here within the first argument is where we name the test. This might be something like MyFirstTest. Give that a save, jump back into our terminal, run this one more time, and now that will
be reflected as MyFirstTest here. We can take running these tests a step further and tell it how we specifically want things to run as well.
For example, if we just wanted to run our unit test suite, excluding functional or browser as we get them later on, we could do that relatively easily with node-ace-test, add
in hyphen hyphen, and then a list of the test suites that we want to run. So we could run just our unit tests here, just like so.
If we rerun this and switch it to functional, then we should get no tests executed right there. Perfect.
We can also run specific files with the files flag, so node-ace-test hyphen hyphen files equals, and then you're probably going to want to put this in quotes, especially if you're using PowerShell.
Some terminal shells don't like arguments being plain text, but we can do tests and point
this to its location, unit, assertions, spec.ts, pointing it to the actual file, including
the file name and extension from the root of our project here. Hit enter to run that, and it should just run that single file.
If we switch this to a file that does not exist, so we'll just do assert.spec, then again we get no tests executed.
We can also run specific tests with node-ace-test hyphen hyphen tests equals, and then again we'll use quotes here, especially because we have spaces.
What we want to do is provide the actual test's name. So that's my first test, which we switched it to here a moment ago.
We hit enter on that, boom, there we go, it runs. If we switch this to a non-existent, we should get no tests executed again.
We can also have this rerun tests automatically as we save our files via node-ace-test hyphen hyphen watch.
If we hit enter here, it's going to add in an extra step of watching our file system for changes. It will run the test initially here, and then if we jump into any of our files, what I'll
do is I'll put that over to the right, and this over to the left. If we hit save, you'll see that it reruns via that save.
Whenever we save inside of a specific specification, it will just rerun that specification. If we save elsewhere inside of our project, like say we add in a plugin, then it will
rerun the entire test as a whole. If we go ahead and stop this with command or control C, depending on your system, and
let's clear that out, node-ace-test, we can see a list of all of the options via hyphen hyphen help. You can see that this command takes in the options that we want to add in, and then we
can end it with hyphen hyphen, and then list out the suites that we want to run as its arguments. So the options entail files, which we covered. There's also tags.
We don't have any tags at the moment. We'll cover those later on. Groups, which would be similar to running by specification. You would just run it via the group's name of assertions right there.
If you'd like to change up the reporter, there's a reporters option for that. These change how our tests are actually output inside of the terminal. There's four different ones. Spec is the default.
That's the one that we've seen thus far, but there's also dot, ndjson, and github for github actions.
ndjson will output it as json, and dot will just use icons without the actual test titles. We have watch, which we covered.
We have pull, which is similar to watch, but rather than watching the file system, it will just pull for file system changes at a set interval.
Add a timeout for your tests, so it will kind of pause in between the tests there. Retries, should a test fail, you can specify a retry count.
So if you set that to three, it will try the same test up to three times before finally failing out. You can add in a failed flag to just run tests that failed during the last run, which can
be handy if you're trying to debug specific tests. We have clear or no clear on whether or not the terminal should clear out in between test runs.
Assets or no assets to determine whether or not the asset bundler server should start, and then asset args for CLI arguments to pass through to the asset bundler.
Additionally here, as you might see inside of my Visual Studio Code, we have this run test and run test for this file, little clickable buttons right up here.
If I click on run test, you'll see that it opens up the terminal inside of Visual Studio Code and runs just this single test. That is provided via an extension.
So if we open up the extensions panel inside of Visual Studio Code, I have the AdonisJS extension pack installed, but you can also get these on an individual basis. So if we open this up, let me close that out there.
This pack includes the Japa extension, which is what is adding specifically these buttons in.
And then this pack also happens to include the AdonisJS extension and Edge Template Syntax Highlighter as well.
If we dig in here to the Japa extension, it does a little bit more than just showing those little button overlays. You can run tests without typing anything. Those are those button overlays.
You can add snippets to it, see snapshots. And then as you can see down here, you can also have a panel open up showing a list of
all of your tests and whether or not they've succeeded, failed, as they are running over on the left-hand side. If you're like me and you have this particular bar right here hidden, you can show that by
going to View, Appearance, Activity Bar Position. You see I have mine set to hidden, you set that to default and it will show up. There's this little beaker right there for testing.
If we click on that, we can see the specific test we have here with a little run button. If we click on that, you can see that it will actually run and show whether or not it succeeded right there.
It shows the group that's inside of it as well as that specific test. So that's a handy little UI-based option if you would like to run tests that way.
For the most part throughout the series, we're going to be making use of the actual runner that we had going just a moment ago. So if we do node-acetest-watch, we'll just kind of leave this going here so that it
automatically changes as we write our tests.

Pragmatic Testing in AdonisJS with Japa

4 Lessons

20m 28s

The Foundations

1

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