4 ms·

Thank you for your comment, maybe I wasn't clear with my statement. I referred to dependency inversion (and therefore also frameworks of it). When using DI you

Thank you for your comment, maybe I wasn't clear with my statement. I referred to dependency inversion (and therefore also frameworks of it). When using DI you have no possibility to define ".asNullable" as you like from case to case, instead a framework is deciding for you. By using DI during tests it's therefore impossible to use the advertised "nullable" pattern as described. Looking at the examples all of the code does not use dependency inversion. https://en.m.wikipedia.org/wiki/Dependency_inversion_principle https://en.m.wikipedia.org/wiki/Dependency_inversion_princip...

jdlshore 4y ago
I know what the dependency inversion principle is. I think there's some fundamental misunderstanding here, because dependency inversion is a design pattern, not a framework, and there's nothing about it that prevents you from using Nullables in your tests. Regardless of whether you're using dependency inversion, or dependency injection, your class under test can be programmed with the following constructor: class MyClass { private MyDependency myDependency; MyClass(MyDependency myDependency) { this.myDependency = myDependency; } // rest of code } This is the fundamental dependency injection pattern. (Well, there's other ways to do it, but this is most common.) No matter what DI framework you're using, you probably have constructors that look like this. If you do, you can use Nullables. And if you don't, all you need to do is add them. It's possible that your DI framework is generating these constructors for you automatically, in which case (1) ewwww, and (2) if you dig into your framework's documentation, there's probably a way to make it work with Nullables.
- SeriousM 4y ago
  DI is a pattern and there are frameworks that help you issuing them - no misunderstanding here. I just wanted to point out that using DI and a framework supporting you using it, you are not in control what you get as dependency. Building the object graph yourself during test setup (and still respecting the rules of DI) will allow you that yet you have a lot more labor to do. In a modern language like C# with it's eco system it's hard and somethimes even impossible to avoid the DI feamework that connects all the services, therefore I was showing a way to get the same effect as the nullable pattern yet using a DI Framework during test setup.
  - zjdev 4y ago
    > I just wanted to point out that using DI and a framework supporting you using it, you are not in control what you get as dependency Not even remotely true. Why are you under the impression that you aren't in control of what dependencies get created and form your object graph? Either you've got a misapprehension or you've got a terrible DI framework

jdlshore 4y ago

I know what the dependency inversion principle is. I think there's some fundamental misunderstanding here, because dependency inversion is a design pattern, not a framework, and there's nothing about it that prevents you from using Nullables in your tests. Regardless of whether you're using dependency inversion, or dependency injection, your class under test can be programmed with the following constructor: class MyClass { private MyDependency myDependency; MyClass(MyDependency myDependency) { this.myDependency = myDependency; } // rest of code } This is the fundamental dependency injection pattern. (Well, there's other ways to do it, but this is most common.) No matter what DI framework you're using, you probably have constructors that look like this. If you do, you can use Nullables. And if you don't, all you need to do is add them. It's possible that your DI framework is generating these constructors for you automatically, in which case (1) ewwww, and (2) if you dig into your framework's documentation, there's probably a way to make it work with Nullables.

SeriousM 4y ago
DI is a pattern and there are frameworks that help you issuing them - no misunderstanding here. I just wanted to point out that using DI and a framework supporting you using it, you are not in control what you get as dependency. Building the object graph yourself during test setup (and still respecting the rules of DI) will allow you that yet you have a lot more labor to do. In a modern language like C# with it's eco system it's hard and somethimes even impossible to avoid the DI feamework that connects all the services, therefore I was showing a way to get the same effect as the nullable pattern yet using a DI Framework during test setup.
- zjdev 4y ago
  > I just wanted to point out that using DI and a framework supporting you using it, you are not in control what you get as dependency Not even remotely true. Why are you under the impression that you aren't in control of what dependencies get created and form your object graph? Either you've got a misapprehension or you've got a terrible DI framework