Last post Mar 15, 2019 08:56 AM by DA924
Mar 14, 2019 05:12 PM|Arby360|LINK
I know there are several courses on Udemy which teach you to write unit testable code but I could not find any that covers Unity IoC wrapper for dependency injections.
Can someone please help me out with the resources to learn the same? I primarily work on ASP.NET MVC .
Mar 14, 2019 09:37 PM|DA924|LINK
If you are writing unit tests, then Unity IoC or any IoC for that matter really has nothing to do with Unit Testing.
Mar 15, 2019 07:58 AM|Yuki Tao|LINK
The two are not related.
I just could give you some about about Creating Unit Tests for ASP.NET MVC Applications:
and Dependency Injection and Inversion of Control with ASP.NET MVC:
Mar 15, 2019 08:56 AM|DA924|LINK
An IoC in general and dependency injection are about this, becuase IoC(s) use Interfaces.
Loose Coupling is achieved by means of a design that promotes single-responsibility and separation of concerns.
A loosely-coupled class can be consumed and tested independently of other (concrete) classes.
Interfaces are powerful tools used for decoupling. Classes can communicate, through interfaces, to other concrete classes, and any class can be on the other end of that communication simply by implementing the interface.
When you’re working in a strongly typed language like C# or Visual Basic, instantiating an object is done with the new keyword. It’s important that we recognize the significance of using this keyword in our code, because I would venture to say that well
over 90% of developers don’t give it a second thought.
Any time you use the new keyword, you are gluing your code to a particular implementation. You are permanently (short of editing, recompiling, and redeploying) hard-coding your application to work with a particular class’s implementation.
New is Glue. It binds your code to a particular collaborator. If there is any chance you’ll need to be flexible about which implementation your code will need, it’s worth introducing an interface to keep your code loosely coupled. It doesn’t matter what
the service is you need – you can always replace it with an interface even if your class is the only one that uses it
Another problem with the maintainability of code like this is that it isn’t honest with its collaborators. You should avoid writing classes that can be instantiated in invalid states, as these are frequent sources of errors. Thus, anything your class needs
in order to perform its tasks should be supplied through its constructor. As the Explicit Dependencies Principle (bit.ly/ED-Principle) states, “Methods and classes should explicitly require any collaborating objects they need in order to function correctly.”