-
Notifications
You must be signed in to change notification settings - Fork 141
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
Feat switch to jest #365
Feat switch to jest #365
Conversation
1 similar comment
🤔 |
I thought you refuse |
@A-312 I was convinced of the interest to switch from js-must. But should.js and chai.js were not good candidates because they both allow the use of property access for assertions cf. /~https://github.com/moll/js-must/#asserting-on-property-access. Chai.js documents the following as recommended EDIT: Of course I should have mentioned Node TAP, which is secure and well designed, that I also considered. But Jest's matchers are more human readable at first glance than TAP's assertions. |
EDIT: They use proxy on their object to avoid this error I tried: }
}
}
}
conf.validate()
expect(conf.has('default')).to.be.lol
expect(conf.getSchemaString()).to.equal(JSON.stringify(expected, null, 2))
expect(conf.getSchemaString(true)).to.equal(JSON.stringify(nodeSchemaExpected, null, 2))
})
}) Seem fine:
I'm not sure to understand the 2nd argument. |
Switch to Jest