-
Notifications
You must be signed in to change notification settings - Fork 917
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
move emulator suite tests into scripts folder #3035
Conversation
Yes, the coverage went down, but there's not much I can do about that at the moment. New, more unity tests would have to be written for some of the emulator parts. |
scripts/emulator-tests/run.sh
Outdated
|
||
# Run the tests from the built dev directory. | ||
mocha \ | ||
--bail \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally we don't use --bail
(although I don't mind), did you intend to do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed.
scripts/emulator-tests/run.sh
Outdated
dev/scripts/emulator-tests/*.spec.* | ||
|
||
# Remove the built artifacts. | ||
rm -rf dev |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this run if mocha fails?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I replaced it with a trap so it will always be run on exit :)
…s into bk-emulator-suite
Description
These tests aren't really "unit" tests as much as they are "integration" or "functional" tests. They take ~500ms each to run, so taking them out of our "unit" test path would speed them up greatly (down to 9s, in fact).
This does a little bit of fancy footwork. The process for these particular tests is this:
dev
directorydev/scripts
using mochadev
It's a little odd, but it allows the fact that it spawns child processes using node and the generated code, making it a bit easier.
The reason I don't want to do this with all the unit tests (even though these tests still take ~10s, which doubles the unit tests runtime) is that I lose the source mappings and coverage information. For some reason, these tests fail in strange ways when I generate the source maps alongside the code (which is why they're disabled).