Senior Software Engineer at Noom, formerly Team Lead Engineering at XING. I intend to write about functional programming and occasionally some random engineering topic.
DI refers to dependency injection, which is basically passing a dependency as a parameter to a function instead of having the function call it directly. For example:
fundoSomething(){fetchItemsFrom("http://someurl.com/items")// this is hardcoding the URL that you want to use}fundoSomething(url:String){fetchItemsFrom(url)// now url is "injected" to the function.}fundoSomething(fetchItems:()->Unit){fetchItems()// you can also choose to pass the whole function}
DI and mocking for testing are related in that you can pass mocks (or stubs) to the function under test. If what you're injecting is a side-effectful function, you can indeed replace it with some mock function that doesn't have side-effects, just for the purposes of testing.
Senior Software Engineer at Noom, formerly Team Lead Engineering at XING. I intend to write about functional programming and occasionally some random engineering topic.
Dependency injection is a concept and the ability to mock is a consequence of this concept, but it's by no means the only benefit.
You could, for example, use some class across different sections of an app but have it behave differently depending on the section. Using the dependency injector you can configure the different instances of the class that will be used in each section.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
DI refers to dependency injection, which is basically passing a dependency as a parameter to a function instead of having the function call it directly. For example:
DI and mocking for testing are related in that you can pass mocks (or stubs) to the function under test. If what you're injecting is a side-effectful function, you can indeed replace it with some mock function that doesn't have side-effects, just for the purposes of testing.
Let me know if it's clearer now!
The only difference I see is that with DI the replaced value can be data.
Sorry. I still believe DI and ability to mock is the same concept - ability to replace a thing down the call chain.
Dependency injection is a concept and the ability to mock is a consequence of this concept, but it's by no means the only benefit.
You could, for example, use some class across different sections of an app but have it behave differently depending on the section. Using the dependency injector you can configure the different instances of the class that will be used in each section.