QA

We are using TestCafe for Quality Assurance.

TestCafe allows to run QA tests without any other dependencies.

Running

We don't use testcafe locally. We encapsulate all QA-related stuff into one docker image. Inside this container we have chromium and firefox installed.

This browsers are chosen as default ones. But you might need other ones.

To run this container:

BASE_TEST_URL="http://your-url" sh docker/testcafe/qa.sh

Read the source code and docs inside docker/testcafe/qa.sh for more information, usage examples, and parameters specifications.

Browser support

TestCafe supports all top browsers including ie11, chrome, and firefox. See official docs on this topic.

If you need more browsers you can enable browserstack or saucelabs.

Custom selectors

Since we use css-modules it is impossible to query elements by css class names. Why?

This is required by design. When working with components you should not rely on css or markup queries. Markup is the only thing available in traditional web. But we have a better thing to look for: components.

Components' names change less than css or markup. And components are higher order representation of your logic.

That's why you should use components' names for querying.

We use testcafe-vue-selectors and testcafe-nuxt-selectors by default.

That's how it works:

import NuxtSelector from 'testcafe-nuxt-selectors'

// To select all comments inside current layout:
const comments = NuxtSelector('Nuxt Comment')

See ./docker/testcafe/fixtures for more examples.

Visual recorder

We also recommend to use a visual recorder to create fixtures for your tests. This way is faster, easier and more reliable.

You can check TestCafe docs for more information.

GitLab CI

We also integrate QA to CI process. But, since all QA tests are very slow we do not force to run them on every commit or pull request.

Instead, we offer a useful and productive way to run these tests. We use when: manual in .gitlab-ci.yml. This way you can manually trigger QA tests to run when you actually need them.

If there are some serious changes or important release run the tests. If this is just a minor change, do not run them to save you some time.

Running tests against real applications

We also encourage to run QA tests against real production websites and apps.

Why? Because you will literally tests how your application behaves in a real world. Covering all possible pitfalls and situations.

How to run QA against our test example?

# Mind the trailing slash, we don't need it!
BASE_TEST_URL='https://wemake-vue-demo.herokuapp.com' sh docker/testcafe/qa.sh

At least, you should have a full production copy to run tests against it.