You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure if this is a bug or a missing feature but essentially when using spectator.triggerEventHandler with a component as the first argument (not just the html selector of the component), when you attempt to give the name of the output as the second argument it only knows about outputs decorated with the @Output decorator and not any outputs that use output or model.
As an example assume we have a Component that is using this component:
when my component goes to try and test how it reacts to outputs from that component we would most likely try to use triggerEventHandler like so:
as you can see it only knows about the decoratorOutput field even though it should know about the signalOutput and signalModel fields as well. You can work around this by doing:
This was fixed in 19.1.0 with in it #672.
Although this version was made it was never released on npmjs, that is the final step that seems to be missing.
Let's hope that someone will release it on npmjs
For now a workaround for your case could be spectator.query('signal-output-test').signalOutput.emit('someValue')
Is this a regression?
No
Description
angular: ^18.2.0
spectator: ^19.0.0
Not sure if this is a bug or a missing feature but essentially when using
spectator.triggerEventHandler
with a component as the first argument (not just the html selector of the component), when you attempt to give the name of the output as the second argument it only knows about outputs decorated with the@Output
decorator and not any outputs that useoutput
ormodel
.As an example assume we have a Component that is using this component:
when my component goes to try and test how it reacts to outputs from that component we would most likely try to use triggerEventHandler like so:
as you can see it only knows about the
decoratorOutput
field even though it should know about thesignalOutput
andsignalModel
fields as well. You can work around this by doing:spectator.triggerEventHandler('signal-output-test', 'signalOutput', 'someValue')
but this isnt as helpful and it doesnt have the same type safety that the other approach does
Please provide a link to a minimal reproduction of the bug
No response
Please provide the exception or error you saw
No response
Please provide the environment you discovered this bug in
No response
Anything else?
No response
Do you want to create a pull request?
No
The text was updated successfully, but these errors were encountered: