-
Notifications
You must be signed in to change notification settings - Fork 665
Description
What problem does this feature solve?
Currently it is impossible to unit test correct initialisation of our components.Testing positive cases such as "does a property exist" after init works well, however with a large library of components we also need to consider negative test cases such as "don't allow component to initialise if required properties are missing" An example is shown below:
describe('Input', () => {
it('fail initialization with no value', () => {
const vm = mount(Input, {
propsData: {},
});
// expecting above to fail due to required prop 'value'
});
});
Currently Vue will report to the console with a warning but really this needs to be caught automatically with larger projects as manually testing and checking coverage simply by using the console is inadequate.
The ability to even configure this at a project level would be useful e.g. throwOnMissingRequiredProps: true
What does the proposed API look like?
For backwards compatibility introduce a runtime variable which would consider whether to throw or report missing required component properties to the console.
Activity
eddyerburgh commentedon Jun 12, 2018
I've looked into a similar feature request—hasValidProps #163.
To add support for that we would need to duplicated the props validation logic in Vue.
I suppose for this feature we could parse the warnings thrown? But I' think that approach could be brittle. We could add a
throwOnWarning
log instead, although I imagine that wouldn't be useful.fungus1487 commentedon Jun 13, 2018
I understand duplicating would lead to long term maintenance issues, another suggestion: is there no way to lean on core vue development team to expose this validation logic in a more modular way? That way vue-test-utils could simply make use of the same validation logic without the maintenance overhead?
beliolfa commentedon Jul 18, 2018
I usually handle this situation with a Spy
jonstorer commentedon Jul 5, 2023
I realize this is old, but mocking a global, like
console.error
, seems really off the mark.