All high-level classes must depend only on Interfaces
-
If you don't DI on a large project, how are you doing unit/int tests? Sure, small project, whatever, but...
-
raddevus wrote:
how many developers really know that concept
I would have assumed devs with some experience would be aware of this. In our shop it's a given because you can't write a unit test with a mocked dependency without using this paradigm. :) It's also one of our pre-interview phone screen questions. There's another subtle aspect to this, though: when using MEF, you can encounter a run-time failure (error constructing a service class) when any dependency in the chain fails to construct because of a missing [Export] attribute on a class in the dependency hierarchy. I didn't want our devs to have to manually check for this so I wrote a tool that reflects the codebase and identifies these broken classes. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
"because you can't write a unit test with a mocked dependency without using this paradigm." An alternative is to use generic programming aka "static polymorphism", and inject dependencies via template parameters. No need for interfaces. Not saying this is a good choice, but it is certainly a choice.
-
"because you can't write a unit test with a mocked dependency without using this paradigm." An alternative is to use generic programming aka "static polymorphism", and inject dependencies via template parameters. No need for interfaces. Not saying this is a good choice, but it is certainly a choice.
That can leading to run time errors because you have to ensure you call the correct overload with the correctly mocked dependency for every method you want to test. It's safer to inject the required mocks (once) into a non-overloaded constructor of the system being tested, because those mocks are guaranteed to be used for all the methods being tested. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
quote
Create a facade around any API that you are using to protect your code from changes in the API.
A great idea that no one ever does. Ok, not no one, but it is done more rarely than it should be. Also, there are physical limitations to it. We use a 3rd party component that has 100s methods. We should wrap the component but it gonna take a while. :)
Why? How difficult is it to adopt the old semantics of a given dependency, and shim a a new replacement library when it becomes necessary to jump ship. I have done this a few times, though not often. Seems like deferring the pain ('YAGNI') until it becomes necessary is optimal overall.
-
Why? How difficult is it to adopt the old semantics of a given dependency, and shim a a new replacement library when it becomes necessary to jump ship. I have done this a few times, though not often. Seems like deferring the pain ('YAGNI') until it becomes necessary is optimal overall.
hpcoder2 wrote:
Seems like deferring the pain ('YAGNI') until it becomes necessary is optimal overall
Yeah, exactly. You can either have: 1) Pain now (All Interfaces) 2) Pain later (that may never occur) I figure take the pain later -- cause a lot of software rots for other reasons and is completely re-written anyways. So, you may never reach the "pain later" stage anyways. As a matter of fact, I've rarely seen it in 35 years of software development. And, when another manager comes in anyways, they think something totally different and wipe away the "old" code, even if it is extensible from all those Interfaces.
-
That can leading to run time errors because you have to ensure you call the correct overload with the correctly mocked dependency for every method you want to test. It's safer to inject the required mocks (once) into a non-overloaded constructor of the system being tested, because those mocks are guaranteed to be used for all the methods being tested. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
The compiler takes care of calling the correct overload. I really don't understand the problem. Pros of the generic solution: - no virtual function overhead Con: - the interface contract is more implicit Other than that, both approaches are about equally as complex and difficult to debug. Better if mocking is not used unless necessary.
-
The compiler takes care of calling the correct overload. I really don't understand the problem. Pros of the generic solution: - no virtual function overhead Con: - the interface contract is more implicit Other than that, both approaches are about equally as complex and difficult to debug. Better if mocking is not used unless necessary.
hpcoder2 wrote:
Better if mocking is not used unless necessary.
How would you unit test a service without mocking its dependencies? /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
jschell wrote:
Far as I can tell you are still telling me about what is is supposed to do.
Sorry, I don't understand. Software engineering best practices don't magically do anything by themself. Developers have to use them correctly in order to benefit from them. Your statement is a bit like saying "Object oriented design has no benefits because it doesn't do what it's supposed to do." If you don't use object oriented programming principles correctly, you're not going to enjoy any of its benefits. It's the same with agile development practices (which IMHO very few organizations follow correctly). /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Which again is just stating how it is supposed to work. As I asked you in the very first post that I made ... Has anyone measured, objective measurements, how successful that is? You are claiming that it is successful. Not that it could be but rather that it is. So how did you measure that?
-
hpcoder2 wrote:
Better if mocking is not used unless necessary.
How would you unit test a service without mocking its dependencies? /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Quite easily. Options include: 1. Black box testing - test the assembled class with its dependencies, based on whatever attributes are publicly visible. 90% of the time this is all that is needed. 2. White box testing - test the assembled class with its dependencies, but also declare internal state as protected, and have the test fixture inherit from the class being tested. 3. White box testing - instead of declaring the internal attributes protected, declare an internal class Test and make it friends with the class being tested. The actual implementation of the test class can be deferred to the unit test code. All of the above I have used in a unit testing environment, and are way simpler to understand, debug and otherwise maintain than dependency injected/mocked code. The only time mocking is really needed is when it is impractical to instantiate the dependency in the CI environment. Examples might include a full database, or something that depends on network resources.
-
Which again is just stating how it is supposed to work. As I asked you in the very first post that I made ... Has anyone measured, objective measurements, how successful that is? You are claiming that it is successful. Not that it could be but rather that it is. So how did you measure that?
jschell wrote:
You are claiming that it is successful. Not that it could be but rather that it is. So how did you measure that?
By measuring our sprint velocity and bug counts. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Quite easily. Options include: 1. Black box testing - test the assembled class with its dependencies, based on whatever attributes are publicly visible. 90% of the time this is all that is needed. 2. White box testing - test the assembled class with its dependencies, but also declare internal state as protected, and have the test fixture inherit from the class being tested. 3. White box testing - instead of declaring the internal attributes protected, declare an internal class Test and make it friends with the class being tested. The actual implementation of the test class can be deferred to the unit test code. All of the above I have used in a unit testing environment, and are way simpler to understand, debug and otherwise maintain than dependency injected/mocked code. The only time mocking is really needed is when it is impractical to instantiate the dependency in the CI environment. Examples might include a full database, or something that depends on network resources.
IMHO, a member friendship violates Liskov.
hpcoder2 wrote:
The only time mocking is really needed is when it is impractical to instantiate the dependency in the CI environment. Examples might include a full database, or something that depends on network resources.
And that's often the case when testing enterprise systems that include several cooperating independent subsystems. That's the case at my shop. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
IMHO, a member friendship violates Liskov.
hpcoder2 wrote:
The only time mocking is really needed is when it is impractical to instantiate the dependency in the CI environment. Examples might include a full database, or something that depends on network resources.
And that's often the case when testing enterprise systems that include several cooperating independent subsystems. That's the case at my shop. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
I have no problem with the independent subsystems being mocked. There are relatively few of these. In examples I've seen, every single class implements an interface, and every interacting class is mocked, leading to triple the number of classes, and a nightmare to read and/or debug the code. Way too much! Re friendship violating Liskov, then so much the worse for Liskov. Friendship has its place and uses, but shouldn't be overused - just like global variables, mutable members and dependency injection.
-
I have no problem with the independent subsystems being mocked. There are relatively few of these. In examples I've seen, every single class implements an interface, and every interacting class is mocked, leading to triple the number of classes, and a nightmare to read and/or debug the code. Way too much! Re friendship violating Liskov, then so much the worse for Liskov. Friendship has its place and uses, but shouldn't be overused - just like global variables, mutable members and dependency injection.
hpcoder2 wrote:
I have no problem with the independent subsystems being mocked. There are relatively few of these.
Right. In our codebase, services tend to have at most about 3-4 dependencies (independent services).
hpcoder2 wrote:
In examples I've seen, every single class implements an interface
Ouch. I agree that's overkill. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
jschell wrote:
You are claiming that it is successful. Not that it could be but rather that it is. So how did you measure that?
By measuring our sprint velocity and bug counts. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
and bug counts.
You originally responded (quoted) to the following "All high-level classes must depend only on Interfaces" Are you claiming that interfaces and nothing else reduced bug counts? Versus and not the same as a large number of other code and process (not just coding) methods. And the sum total of those reduced bug counts? And what was your time period and measurement. So for example you started with no processes in place in Jan of 2021, and you measured your production bug rate then for the last year (to Jan of 2020.) Then you implemented the new processes and now your production bug rate is 50% less? Or 90% less? Specifically what are those numbers? (Might note that I spend 15 years doing significant/principle work in Process Control procedures so I am fact rather knowledgeable both in the theory and the practice and the reality of doing this.)
-
Ravi Bhavnani wrote:
and bug counts.
You originally responded (quoted) to the following "All high-level classes must depend only on Interfaces" Are you claiming that interfaces and nothing else reduced bug counts? Versus and not the same as a large number of other code and process (not just coding) methods. And the sum total of those reduced bug counts? And what was your time period and measurement. So for example you started with no processes in place in Jan of 2021, and you measured your production bug rate then for the last year (to Jan of 2020.) Then you implemented the new processes and now your production bug rate is 50% less? Or 90% less? Specifically what are those numbers? (Might note that I spend 15 years doing significant/principle work in Process Control procedures so I am fact rather knowledgeable both in the theory and the practice and the reality of doing this.)
jschell wrote:
Are you claiming that interfaces and nothing else reduced bug counts?
Obviously not.
jschell wrote:
I am fact rather knowledgeable both in the theory and the practice and the reality of doing this.)
Yes, we're all very impressed by your intellect. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
jschell wrote:
Are you claiming that interfaces and nothing else reduced bug counts?
Obviously not.
jschell wrote:
I am fact rather knowledgeable both in the theory and the practice and the reality of doing this.)
Yes, we're all very impressed by your intellect. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
Yes, we're all very impressed by your intellect.
And yet I do know what I am talking about. While you keep responding but fail to answer the original question - how did you specifically measure the improvement? - What was your specific improvement.? I know that the answers to both those questions are available if in fact you are following stringent Process Control processes. And those processes would demonstrate that your original claim is in fact correct. Versus, as I said, applying it with the expectation of an improvement without any backing for that. That supposition would not be unique to you of course. I have seen many people make the claim. But who were unaware of that vast body of work that does in fact show that improvements (objective measured) are possible. But only if one does the actual work, including the Process Control processes.
-
Ravi Bhavnani wrote:
Yes, we're all very impressed by your intellect.
And yet I do know what I am talking about. While you keep responding but fail to answer the original question - how did you specifically measure the improvement? - What was your specific improvement.? I know that the answers to both those questions are available if in fact you are following stringent Process Control processes. And those processes would demonstrate that your original claim is in fact correct. Versus, as I said, applying it with the expectation of an improvement without any backing for that. That supposition would not be unique to you of course. I have seen many people make the claim. But who were unaware of that vast body of work that does in fact show that improvements (objective measured) are possible. But only if one does the actual work, including the Process Control processes.
jschell wrote:
While you keep responding but fail to answer the original question - how did you specifically measure the improvement? - What was your specific improvement.?
Actually I did answer your questions. Perhaps you missed reading my reply of 27-Feb-2024 10.46. Here it is again:
Ravi Bhavnani wrote:
By measuring our sprint velocity and bug counts.
The increase in sprint velocity showed we were able to release new and modified functionality consistently faster (without growing our team), and the reduction in issues per new feature/enhancement spoke to better code quality brought about by the increase in the number of unit tests. Defining our injected dependencies as interfaces (vs. concrete classes) makes it easier to write unit tests because it's trivial to mock them. This is especially true when many of our service dependencies are implemented by other teams. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
jschell wrote:
While you keep responding but fail to answer the original question - how did you specifically measure the improvement? - What was your specific improvement.?
Actually I did answer your questions. Perhaps you missed reading my reply of 27-Feb-2024 10.46. Here it is again:
Ravi Bhavnani wrote:
By measuring our sprint velocity and bug counts.
The increase in sprint velocity showed we were able to release new and modified functionality consistently faster (without growing our team), and the reduction in issues per new feature/enhancement spoke to better code quality brought about by the increase in the number of unit tests. Defining our injected dependencies as interfaces (vs. concrete classes) makes it easier to write unit tests because it's trivial to mock them. This is especially true when many of our service dependencies are implemented by other teams. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
First of course those are not numbers. Second I responded to you and said the following... "Are you claiming that interfaces and nothing else reduced bug counts?"
Ravi Bhavnani wrote:
The increase in sprint velocity showed we were able to release new and modified functionality
Yes one can modify coding practices and development processes to achieve various measurable benefits. But you cannot due that solely by using interfaces. Please read the Original Post. It says nothing about a comprehensive rework of coding practices and development processes. It says that nothing but requiring interfaces is being required.
-
First of course those are not numbers. Second I responded to you and said the following... "Are you claiming that interfaces and nothing else reduced bug counts?"
Ravi Bhavnani wrote:
The increase in sprint velocity showed we were able to release new and modified functionality
Yes one can modify coding practices and development processes to achieve various measurable benefits. But you cannot due that solely by using interfaces. Please read the Original Post. It says nothing about a comprehensive rework of coding practices and development processes. It says that nothing but requiring interfaces is being required.
jschell wrote:
First of course those are not numbers.
Do you mean sprint velocity, code coverage and bug counts aren't numbers?
jschell wrote:
But you cannot due that solely by using interfaces.
Correct. And I didn't imply you could. Read my comment of 17-Feb-24 13:11 again. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
jschell wrote:
First of course those are not numbers.
Do you mean sprint velocity, code coverage and bug counts aren't numbers?
jschell wrote:
But you cannot due that solely by using interfaces.
Correct. And I didn't imply you could. Read my comment of 17-Feb-24 13:11 again. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
Do you mean sprint velocity, code coverage and bug counts aren't numbers?
No. Those are measurable quantities which over time can reflect a change. A number is 3. You could state that you improved 30%. Or that your average bug count went from 30 to 3. Those are numbers.
Ravi Bhavnani wrote:
Correct. And I didn't imply you could. Read my comment of 17-Feb-24 13:11 again.
Stating it again.... The OP said that the ONLY thing requested was adding interfaces. Nothing else. You responded directly to that, you quoted that line from the OP. And stated you "follow that guideline at my shop." You did not qualify that by suggesting that it was part of a larger process that would lead to better code. Perhaps you meant to encompass the entire development process but that is NOT what you said in your original post.