We are using
TestCafe for Quality Assurance.
TestCafe allows to run QA tests without any other dependencies.
We don't use
testcafe locally. We encapsulate all QA-related stuff into one
docker image. Inside this container we have
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.
TestCafe supports all top browsers including
firefox. See official docs on this topic.
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.
That's how it works:
import NuxtSelector from 'testcafe-nuxt-selectors'// To select all comments inside current layout:const comments = NuxtSelector('Nuxt Comment')
./docker/testcafe/fixtures for more examples.
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.
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.
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.