Unit testing is where the action is. Unit testing is very straightforward provided your code is testable. This requires inversion of control. Any time that you have code that initializes stuff as a side effect of being used, or imported, you are creating a testability problem. You can no longer consider the unit in isolation since it fires up stuff that fires up more stuff, etc.
Lambda functions make this even worse. Now you have a class with a constructor that constructs other things than itself (simple guideline: constructors must not do work) and then inserts lambdas in those things that do the actual things you need to test. All inside a constructor that gets called from another constructor. Add promises to the mix and you have a perfect horror show of asynchronous side effects of a things being created that may or may not fire events, etc. Simulating all of that in a unit test is hard. This code is effectively hard to test.
The way out is simple: design for testability. IOC is one of several tools you can use and a crucial one but step 0 is acknowledging that what some people claim is elegant is in fact inherently untestable and therefore something needs to change.
Thank you for this insightful reply! It makes a lot of sense. I would also add that doing testing the right way (and not just to check a box) transforms the way developers approach code. It's like words: tough for a toddler to communicate with only a few, but an adult can convey very complex thoughts by using the right words as building blocks. Having a test-conscious approach and leveraging patterns like IoC improve your "developer vocabulary" and helps simplify the expression of code.
Great post, appreciate the simple explanation.
Just checking, is this line a typo on "piston"?
var piston = $jsInject.get("piston");
Just wondering if it should be "pistons" since that is the label you registered it with or if I'm misunderstanding. Thanks!
Great catch! It was a typo and I updated the article. Thanks for the good eyes on this.
Thanks for this post. It actually made me excited like Christmas. I have been trying to work out how and why this is useful and your example clears up all doubts I might have had.
Next, how do I get my team to adopt this pattern? :)
I always prefer to lead by example and show the value it provides so they want to adopt it.
Incredible! But one doubt: when you'll use ".register", you've to specify first the label and then the class, right?
Correct. In the simple DI example you pass a label (string), then an array that should have the function constructor, factory, or instance as the last element.
Great! And in this case: "$jsInject.register("engine", ["pistons", Engine]);", you have to pass the "pistons" in the array too because "Engine" receives "pistons" as a parameter, right? And then the last element would be "Engine" cuz is the "current class".
You got it! The important part of the illustration is that "pistons" is just a label, not an implementation, so you have flexibility to define it however you see fit elsewhere.
Oh, I get it! Then I'll use this label on "$jsInject.get()". Amazing!! Thanks ;)
Thanks for the post Jeremy 👋
A question I've been mulling over while reading.
Can the terms IoC and DI be used interchangeably?
My pleasure! The easiest way for me to summarize it is this:
Inversion of Control is a concept/abstraction and Dependency Injection is a specific implementation of that abstraction.
Ah. so IoC is a blueprint and DI is like a house.
Thanks, Jeremy 👊
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.