Anytime we go into a project, existent or newly created, we always think about how what we'll build can be more manageable, scalable and and easy...
For further actions, you may consider blocking this person and/or reporting abuse
Did you know that Jest can mock your modules?
jestjs.io/docs/en/mock-functions.h...
Hi Brian,
Yes, I do know Jest can achieve that but in my eyes that's kind of bit of magic... Having to import the direct modules installed via
npmin the tests files and then override them with with another lib just doesn't feel right to me...What about when I change that lib for some reason? I'm required to go to that file and change that by having lot of tests broken at that point, and I'll also have to change every module file in order to reflect the replacement which can be avoided using this approach. I prefer abstracting that responsibility of my modules and mocked them myself.
Hope this clarifies my point of view to you. Also, thank you for bringing the Jest fact here, so other guys knows there are already alternatives for this if they didn't know before.
Agree on the mocking. It feels dangerous to be faking npm modules to try and gain control of your test. Much simpler with injection and you aren't getting tied up in the mocking/unmocking workflows
Isn't that the whole point though? You inject the npm modules with the sole purpose of mocking them. So in your unit test, you're not testing axios' connection to the web service, but via mocking, you can intercept those calls and stub a response for your unit test.
Hi Nick, thank you for taking your time and reading this post.
I believe we as developers need to make conscience about how important is making our code as testable, reusable and simple as we can.
We are not the only ones that are going to work in the codebase, we need to make things easier for future maintainers, and companies so what we've built can prevent horrible errors along the road.
If the dependencies are updated and the API changed, then our test will not' fail because the mocks did not get updated.
Which is why integration tests should always be done with real dependencies.
On top of that dependency injection is a anti-pattern on the level of inflection and convention over configuration.
It's hard to debug, hard to test, and hard to maintain or requires a lot of domain knowledge.
We have functional programming patterns today, which can serve the same purposes but without the drawbacks listed above.
TL;DR
Use arguments, not dependency injection.
Dependency injection is how you get AngularJS (and Angular for mysterious reasons).
Edit, Mis-worded a sentence.
I like that but I find poor man's dependency injection to be more explicit while achieving the same result.