Getting Started with Automated Testing

Web application developers today focus on two kinds of automated testing.Web application developers today focus on two kinds of automated testing. The first is unit testing, which is a

                                              Isolation 

1. The first is unit testing, which is away to specify and verify the behavior of individual classes (or other small units of code) in isolation from the rest of the application.

                                        Working together

1. The second type is integration testing, which is a way to specify and verify the behavior of multiple components working together, up to and including the entire Web application.

                                     Understanding Unit Testing

unit testing helps me structure my thoughts about how to best implement what I need.

 I find that just thinking about what I test helps throw up ideas about potential problems–and that’s before I start dealing with actual bugs and defects.

                              Using TDD and the Red-Green-Refactor Workflow

test-driven development (TDD) you use unit tests to help design your code.

This can be an odd concept if you are used to

testing after you have finished coding, but there is a lot of sense in this approach. The key concept is a development workflow

called red-green-refactor. It works like this:

• Determine that you need to add a new feature or method to your application.
• Write the test that will validate the behavior of the new feature when it is written.
• Run the test and get a red light
• Write the code that implements the new feature.
• Run the test again and correct the code until you get a green light.
• Refactor the code if required. For example, reorganize the statements, rename the variables, and so on.
• Run the test to confirm that your changes have not changed the behavior of your additions.

          

Using a Dependency Injection Container

Using a Dependency Injection Container

Problem 

I have resolved my dependency issue, but how do I instantiate the concrete implementation of interfaces without creating

dependencies somewhere else in the application?

As it stands, I still have to have statements somewhere in the application like

these:

...

IEmailSender sender = new MyEmailSender();

helper = new PasswordResetHelper(sender);

Solution 

The answer is to use a dependency injection container, also known as an IoC container. This is a component that acts as a

broker between the dependencies that a class like PasswordResetHelper declares and the classes that can be used to

resolve those dependencies, such as MyEmailSender.

Breaking and Declaring Dependencies

First part

There are two parts to the DI pattern. The first is that I remove any dependencies on concrete classes from my component—in this case PasswordResetHelper. I do this by creating a class constructor that accepts implementations of the interfaces
I need as arguments, like this:

• Remove 

1. any dependencies from my component—in this case PasswordResetHelper

• Create 

1.  a class constructor that accepts implementations of the interfaces

public class PasswordResetHelper {
private IEmailSender emailSender;
public PasswordResetHelper(IEmailSender emailSenderParam) {
emailSender = emailSenderParam;
}
public void ResetPassword() {
// ...call interface methods to configure e-mail details...
emailSender.SendEmail();
}
}

By creating a class constructor that accept implementations of the interfaces I can remove any dependency.

Second part 

The second part of the DI pattern is to inject the dependencies declared by the PasswordResetHelper class when I

create instances of it, hence the term dependency injection.

• create

1.  instances

•  declared

1. By the PasswordResetHelper 

• inject 

1. the dependencies

All this really means is that I need to decide which class that implements the IEmailSender interface I am going to use,

create an object from that class and then pass the object as an argument to the PasswordResetHelper constructor.

Why do I need dependency injection

Background
separation of concerns in MVC
One of the important feature of the MVC it enables separation of concerns.
 independent as possible
I want the components in my
applications to be as independent as possible and to have as few interdependencies as I can arrange

 abstract interfaces
In an ideal situation, each component knows nothing about any other component and only deals with other areas of the
application through abstract interfaces. This is known as loose coupling, and it makes testing and modifying applications easier.

Example 
A simple example will help put things in context. If I am writing a component called MyEmailSender that will send emails,
I would implement an interface that defines all of the public functions required to send an e-mail, which I would call IEmailSender.

Any other component of my application that needs to send an e-mail—let’s say a password reset helper called
PasswordResetHelper—can then send an e-mail by referring only to the methods in the interface. There is no direct

dependency between PasswordResetHelper and MyEmailSender.

By introducing IEmailSender, I ensure that there is no direct dependency between PasswordResetHelper and
MyEmailSender. I could replace MyEmailSender with another e-mail provider or even use a mock implementation


Problem: objects that implement interfaces

Interfaces help decouple components, but I still face a problem: C# doesn’t provide a built-in way to easily create objects that
implement interfaces, except to create an instance of the concrete component with the new keyword. I end up with code like

this:

public class PasswordResetHelper {
public void ResetPassword() {
IEmailSender mySender = new MyEmailSender() ;
//...call interface methods to configure e-mail details...
mySender.SendEmail();

}
made things worse 
This undermines my goal of being able to replace MyEmailSender without having to change PasswordReset
helper and means that I am only part of the way to loosely coupled components. The PasswordResetHelper class is
configuring and sending e-mails through the IEmailSender interface, but to create an object that implements that interface,
it had to create an instance of MyEmailSender. In fact, I have made things worse for myself because
PasswordResetHelper now depends on the MyEmailSender class and the IEmailSender interface, as


By using interface you make the class depending on each other and that is against the separation of concerns in MVC.

solution 

What I need is a way to get objects that implement an interface without having to create the object directly. The solution to this
problem is called dependency injection (DI), also known as Inversion of Control (IoC).
DI is a design pattern that completes the loose coupling process. As I describe DI, you might wonder what the fuss is about,

but bear with me—this is an important concept that is central to effective MVC development and it can cause a lot of confusion.