4 ms·
The blog post is quite interesting to read! One tradeoff I found is that it doesn't work with dependency injection. I use c# for about 20 years and DI is the be
by SeriousM 4y ago
The blog post is quite interesting to read! One tradeoff I found is that it doesn't work with dependency injection. I use c# for about 20 years and DI is the best, IMHO, that was adapted my Microsoft not too long ago.
When we're writing code against external systems we define wrappers. During test startup we replace the real implementation DI registration with a Moq (usually strict mode) or a concrete testable implementation.
This way we get the nullable-instance into the dependency graph. This is certainly not the fastest way (measured against thousandsof tests), but it works for the team very well.
- jdlshore 4y agoI'm not sure what you're getting at. Look at the examples. They all use dependency injection. Maybe you meant dependency injection frameworks? That's not true either; it works exactly the same way as any other approach: the DI framework injects production objects, and the tests inject their own test objects.
- SeriousM 4y agoThank 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 agoI 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 agoDI 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