Test suite for MagicMirror²
Hi, I recently pushed a Pull Request with two e2e testing.
These use their own configurations like @qistoph mention and after added the MM_CONFIG_FILE variable for MagicMirror.
It’s really easy create new test for check a different part of MagicMirror and their modules.
@roramirez what is the reason for a 10 sec timeout in each test? If there are a many tests this will sum up
what is the reason for a 10 sec timeout in each test? If there are a many tests this will sum up
It’s does not accumulate. It’s a timeout, the maximun time for the test. You can set different timeout for every test.
I haven’t looked thoroughly at the code and I wanted to suggest setting a default timeout that can be overwritten in individual tests as needed. It may make test code a little bit cleaner and less repetitive.
Good job getting it going!
@morozgrafix Yes, I knowed is not more cleaner and repetitive but was the first proof of concept
Good idea set default timeout. I added two new task in Trello board about you mentioned.
@roramirez I’ve played a little with test suite and added basic test for clock module. Then I realized that if we want to test different config options for a given module we may need to have to create multiple configs, which may be challenging with current tests directory organization.
Also I believe that
process.env.MM_CONFIG_FILE = "tests/confs/config_name.js"line needs to be moved into
beforestep (seems to work there or it can go into
beforeEachif needed). Otherwise when running
npm run test:e2efirst config that gets picked up seems to persist throughout all of the tests and always used by the
I was wondering if structure similar to this makes sense:
tests ├── configs │ ├── env.js │ └── modules │ │ └── clock │ │ │ └── clock_12hr.js │ │ │ └── clock_24hr.js │ │ │ └── clock_analog.js │ │ └── helloworld │ │ └── helloworld.js ├── e2e │ ├── env_spec.js │ └── modules │ ├── clock_spec.js │ └── helloworld_spec.js ├── functions │ └── compare-version_spec.js └── global_vars └── root_path.js
but this would involve changingI think that’s easily solved by just changing it to
app.use("/tests/confs", express.static(path.resolve(global.root_path + "/tests/confs")));in the
server.jsto be somewhat dynamic and I’m not very familiar with express on how it can be done.
app.use("/tests/configs", express.static(path.resolve(global.root_path + "/tests/configs")));
@morozgrafix Seem good sense going to a refactor of the structure.
I think we can take two way acord you mentioned.
1.- Include your test for clock module with new format for name and respective directories
2.- Do it the refactor to all tests that remain.
I really like see how you resolve the multiples instances configuration in a one tests file.
@roramirez cool thanks. I have it all ready on my fork. Will submit PR for review.
Two commits I’ve worked on for the testing.
Check keys in the translation files. Produces errors currently, so I’ve added
To prevent loading
app.jsfrom corrupting the Mocha test environment, I suggest to execute the
app.jsin a virtual environment. This can also serve as an example for future test cases where code needs to be executed in the
Any thoughts before I submit a PR?
@qistoph i like the idea of the sandbox
is there a way to just warn instead of error for missing translation keys?