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
This is great tool for writing my tests, however I've noticed that both with and without noCallThru(), if we stub a library and write out our test cases, if the underlying module methods then change, our test cases continue to work, even though the underlying methods have changed. The running code would obviously break, but the tests seems to behave just fine.
Would it be possible to warn or even fail when stubbing functions on require()'d modules that don't actually exist?
The text was updated successfully, but these errors were encountered:
It feels like two things are in conflict here. If you want to use noCallThru to ensure that your stub will be passed exactly instead of merged into the original module, proxyquire doesn't load your original module. To get errors about differences between your stub and the original module, you'd have to load the original. So this definitely doesn't fit into noCallThru. Maybe it could fit in with callThru, namely offering an option to throw if any key in the stub is not present on the original.
It's going to be tricky to shoehorn this into the current API but I'm happy to hear any thoughts if you have them on how we might do it.
This is great tool for writing my tests, however I've noticed that both with and without
noCallThru()
, if we stub a library and write out our test cases, if the underlying module methods then change, our test cases continue to work, even though the underlying methods have changed. The running code would obviously break, but the tests seems to behave just fine.Would it be possible to warn or even fail when stubbing functions on
require()
'd modules that don't actually exist?The text was updated successfully, but these errors were encountered: