Additionally - Dependency Injection in general. If you do add a second realization later, you have the first realizations reference everywhere (testability) and must rewrite everything.
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
Assume you have a class Car which depends on a class DieselEngine. It would not be possible to write a unit test just for the Car when the concrete type DieselEngine is required from the Car constructor. Instead, the test have then to be written keeping in mind that also the concrete implementation for DieselEngine is going to be tested.
When you extract an interface IEngine, you can write a test for the Car itself again (without relying on concrete DieselEngine). Typically you do not have to create another realization of the IEngine interface - instead you can use a mocking framework which does this for you, and check if the method IEngine.Start is only called if the engine is currently off.
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
"Assume you have a class Car which depends on a class DieselEngine. It would not be possible to write a unit test just for the Car when the concrete type DieselEngine is required from the Car constructor."
Why not test the Car with a DieselEngine ? This is a real business scenario
Also, IMHO , Callling an interface IEngine is another smell. Even dough I know it is a standard practice.
Can I use your code snippet in another smell ?
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
It depends on what you call a unit I think, bit you're right. If the DieselEngine is testable at all (could be a real DieselEngine which is not availabe during CI test run, etc).
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
I mostly agree with you opition, except a single thing: tests. I almost ever extract an interface for logic classes to write tests.
Additionally - Dependency Injection in general. If you do add a second realization later, you have the first realizations reference everywhere (testability) and must rewrite everything.
Exactly. That is a valid counterexample. I'll add it
Done!
Thank you for being that open! 😁
And how many realizations do you have ?
Typically just a single "real" one, the other ones are created by mocking frameworks (like NSubstitue for .NET)
I don't follow your tests example
Can you add a small piece of code as an example?
Assume you have a class
Car
which depends on a classDieselEngine
. It would not be possible to write a unit test just for theCar
when the concrete typeDieselEngine
is required from theCar
constructor. Instead, the test have then to be written keeping in mind that also the concrete implementation forDieselEngine
is going to be tested.When you extract an interface
IEngine
, you can write a test for theCar
itself again (without relying on concreteDieselEngine
). Typically you do not have to create another realization of theIEngine
interface - instead you can use a mocking framework which does this for you, and check if the methodIEngine.Start
is only called if the engine is currently off.I hope this answers your question
Thank you very much for the code.
I think the problem is here
"Assume you have a class Car which depends on a class DieselEngine. It would not be possible to write a unit test just for the Car when the concrete type DieselEngine is required from the Car constructor."
Why not test the Car with a DieselEngine ? This is a real business scenario
Also, IMHO , Callling an interface IEngine is another smell. Even dough I know it is a standard practice.
Can I use your code snippet in another smell ?
"Why not test the Car with a DieselEngine ?" - This is idea behind unit tests :) to have a single unit under the test.
If you do unit testing in your project - you will always have two implementations of your interfaces.
"This is a real business scenario" - Testing of business scenarios is just an another kind of tests.
Right !
You have two interfaces realizations. Therefore this code smell does not apply anymore
Yes feel free.
It depends on what you call a unit I think, bit you're right. If the DieselEngine is testable at all (could be a real DieselEngine which is not availabe during CI test run, etc).
Build your abstractions with TDD so they will be testaable from their inception