Senior Software Engineer at Noom, formerly Team Lead Engineering at XING. I intend to write about functional programming and occasionally some random engineering topic.
I generally agree that mocking is a smell. Note that mocking refers to a testing technique, it's not a synonym for DI. Strictly speaking, mocking is about verifying that certain methods are called on some object and as such you're testing implementation details. See here.
Testing implementation details has the problem that it makes tests more difficult to maintain. For example, if you change the name of the method you're expecting to be called, you have to change all the tests that depend on this method, but the behavior may be exactly the same.
I mock only I/O related things in my tests. Thus I call it mocking. Probably wrong term usage. Apologies.
Do I understand it right that a way of replacing side effect function is called DI in the article above?
And isn't it just a way to mock that function?
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.
Thanks a lot, I'm very glad to hear that!
I generally agree that mocking is a smell. Note that mocking refers to a testing technique, it's not a synonym for DI. Strictly speaking, mocking is about verifying that certain methods are called on some object and as such you're testing implementation details. See here.
Testing implementation details has the problem that it makes tests more difficult to maintain. For example, if you change the name of the method you're expecting to be called, you have to change all the tests that depend on this method, but the behavior may be exactly the same.
I prefer feature testing and avoid mocking as much as possible. Check these resources:
blog.twitter.com/engineering/en_us...
blog.kentcdodds.com/write-tests-no...
I mock only I/O related things in my tests. Thus I call it mocking. Probably wrong term usage. Apologies.
Do I understand it right that a way of replacing side effect function is called DI in the article above?
And isn't it just a way to mock that function?
I'm confused.
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.