-
-
Notifications
You must be signed in to change notification settings - Fork 298
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
[WIP] testing guidelines #449
Comments
huge 👍 to this. though it's not just style, so I would rather call it "testing guidelines". |
Big thanks for getting this started @SBoudrias! We've needed this for a while. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Yeoman testing guidelines
This testing guide is based on Mocha BDD interface (
describe
/it
).Main principles
Tests must be always start with a clean state
This means prefer
beforeEach
tobefore
. Re-instantiate objects before running eachit
blocks. Create every files required by a test in abeforeEach
(or commit them infixtures/
). Reset any side effets done on the test environment after each test.Tests must be runnable in isolation
Each test must pass if they're runned alone. You can run a single test by using
mocha test.js --grep 'test name'
.Stub most performance heavy operation
When possible, always stub networks or other long operations.
We use sinon.js for most stubbing needs.
Naming convention
describe
blocks should cover three types of information: Object to be tested, method/property, circumstantial group (basically, "when this").it
blocks cover assertions. They should use as few lines of code as possible. There should be as manyit
block as there is assertion on a method effect.Instances methods and property should be prefixed by a bang sign (
#find()
). Static methods and property should be prefixed by a dot (.exclude()
).Methods should end using parentheses, but should not include expected parameters (parameters should be cover in documentation comments).
it
blocks should be declarative.Assertion
Don't add
message
to assertions unless the error thrown makes it unclear what failed.If you must add a message, then describe the expected outcome and why it failed. For example:
Remember that these message are the error message thrown with the failure. Let those be useful in these occasions.
Stylistic preferences
.bind()
throwing assertionsWhen testing that a method throw with invalid parameters, prefer binding the parameters to creating an anonymous function.
The text was updated successfully, but these errors were encountered: