TestCafe: Organizing Tests with Metadata

Marques Woodson
Mar 25 · 2 min read

If you want to learn more about TestCafe, please check out my course End-to-end Web Testing with TestCafe: Getting Started on Pluralsight.

The TestCafe framework has a nice little feature for fixture and test organization. All fixtures and tests have an optional meta property that you can use to attach any additional information. Let’s look at how we can use this meta property for more granular test runs. We’ll first look at a couple of different ways to filter your tests.

Filter by filename

This I think is the most common way of splitting up your tests. You would put your authentication tests in a file like authentication.spec.ts, or profile page tests in profile.spec.ts, etc. What if you want to run a subset of those tests as smoke tests? Or you have a set of tests that you only want to run in Internet Explorer or Safari? If you are relying on file names, you could do something like create a file named smoke-tests.spec.ts, and copy/paste into it any tests you would want for a smoke test run. This requires duplication of testing code though, and can be difficult to maintain.

Filter by fixture or test name

You can filter what tests are run just by the fixture name:

$ testcafe chrome login.spec.ts --fixture "Bad Passwords"
# or by regular expression
$ testcafe chrome login.spec.ts --fixture-grep "Bad.*"

To tell TestCafe what fixtures/tests will be smoke tests, you could name your fixtures something like:

fixture('Bad Passwords: smoke'); test('Incorrect passwords should show an error: smoke');

Then you could filter with:

--fixture-grep "smoke"
# or
--test-grep "smoke"

This could make the fixture names brittle, however. What if a fixture name has the word “smoke” in it, even though you don’t want it to be a smoke test?

Filter using metadata

We can use the meta property to create a subset of tests like this:

// login.spec.js 
fixture('Login Page')
.page('https://some-app.com')
.meta('smokeTest, true)
.meta('ieOnly', true);
// Or you can pass an object instead

.meta({ smokeTest: true, ieOnly: true})

With the meta property in place, you can now run tests like this:

$ testcafe chrome login.spec.js --fixture-meta smokeTest=true

You can even use the meta property on a test:

// login.spec.js 
fixture('Login Page')
.page('https://some-app.com');
test('should show an error with incorrect username', …)
.meta({ smokeTest: true });

and you can use the

--test-meta

option just like the

--fixture-meta

option:

$ testcafe chrome login.spec.js --test-meta smokeTest=true

Now we have a clean way of creating test subsets that don’t rely on fixture/test name, or file name. Not only can metadata be used for filtering tests, but that information can be used in your own custom test reports.

Conclusion

TestCafe’s metadata feature makes it simple to separate and organize test runs within your end to end suite, not only at a fixture level, but at the test level. I think you should definitely work it into your tests to get the most out of TestCafe.

software engineer, father, lover of technology, striver of learning

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade