Thanks for writing tests! Here's a quick run-down on our current setup.
Please familiarise yourself with these if you plan on contributing! 👍
Material-UI uses a wide range of tests approach as each of them comes with a different trade-off, mainly completeness vs. speed.
To run all of the unit tests just run yarn test:unit
If you want to grep
for certain tests just add -- -g STRING_TO_GREP
and change STRING_TO_GREP.
yarn test:watch
First, we have the unit test suite.
It uses mocha and the shallow API of enzyme to allow testing the components in isolation.
It's the fastest approach, and is best suited for testing many combinations.
Here is an example with the Menu
component.
Next, we have the integration tests.
We are using the mount API of enzyme.
It allows testing the integration of different components using a virtual DOM.
This virtual DOM is provided by jsdom.
It's here to make sure components work together.
Here is an example with the Menu
component.
yarn test:coverage:html
When running this command you should get under coverage/index.html
a full coverage report in HTML format. This is created using Istanbul's HTML reporter and gives good data such as line, branch and function coverage.
yarn test:karma
Testing the components at the React level isn't enough; we need to make sure they will behave as expected with a real DOM. To solve that problem we use karma, which is almost a drop in replacement of jsdom. Our tests run on different browsers to increase the coverage:
- PhantomJS - Scriptable Headless WebKit
- Firefox, Chrome and Safari thanks to BrowserStack
In the end, components are going to be used in a real browser. The DOM is just one dimension of that environment, so we also need to take into account the rendering engine.
yarn test:regressions
Next, we are using docker to take screenshots and comparing them with the baseline. It allows catching regressions like this one:
Here is an example with the Menu
component.
The visual regression tests suite has a hard dependency on docker. You need to install it, then run the following commands:
docker-compose up -d
Due to issues with networking in OS X, getting the container to see the
test page may require additional configuration as the docker0
interface
does not exist.
You can create an alias for the loopback interface using the instructions provided at https://docs.docker.com/docker-for-mac/networking/#/there-is-no-docker0-bridge-on-macos
sudo ifconfig lo0 alias 10.200.10.1/24
In our vrtest
config this is set as the default, although it can be overridden with an env var:
testUrl: process.env.DOCKER_TEST_URL || 'http://10.200.10.1:3090',
In addition to docker, the visual regression tests depend on either ImageMagick or GraphicsMagick being installed.
For all unit tests, please use the shallow renderer from enzyme
unless the Component being tested requires a DOM. Here's a small shallow rendered test to get you started.
If the Component being unit tested requires a DOM, you can use the mount api from enzyme
. For some operations, you may still need to use the React test utils, but try to use the enzyme
API as much as possible.
Stick to test assertions such as assert.strictEqual
and assert.ok
. This helps keep tests simple and readable.
We should try to use as many demos from the documentation as possible; however, we can't replace one with the other as they address different needs. With the regression tests:
- You might need to test a more complex situation, e.g. a stress test of the grid
- You might need to test a simpler situation, e.g. a static progress bar