Introduction
In this article we will see how to Unit Test a MVC4 application with Dependency Injection.
Steps
The MVC application we will be using is already explained to a previous article. As explained in the previous article, we have a "GuestBook" controller as explained below.
One of the issues with the current implementation of the "GuestbookController" is that it directly instantiates and uses the "GuestbookContext" object, which in turn accesses the database.
The solution to this is to decouple the controller from the GuestbookContext. Instead of accessing the "GuestBook" data directly from the DB, we will create a repository as below.
A concrete class that implements the "IGuestBookRepository" interface method is created as in the following:
Note that this concrete class has the direct reference to the "DBContext". Let's integrate this repository into the "GuestBook" controller.
Before making any changes to the "GuestBook" controller, remove the DBcontext code and create a local variable to hold the "IGuestBookRepository" interface instance.
Rather than instantiating the GuestbookContext, we now store an instance of our repository within a field. The controller's default constructor populates the field with the default implementation of the repository. The second constructor allows us to provide our own instance of the repository rather than the default. This is what we'll use in our unit tests to pass in a fake implementation of the repository.
The actions in our controller now use the repository, instead of using the LINQ queries that will do the direct DB call.
All these changes are for removing the dependency with the database and we make the existing application work without any issues.
Create a simple fake repository as below that implements the "IGuestbookRepository" interface.
Let's start to create a new unit test project from an existing application.
Create a new test method that is using our Fake repository:
Create a complex test method like the following one, it asserts that a list of "Guestbook" objects was passed to the view.
Both tests make use of the fake repository "B". By passing it to the controller's constructor, we ensure that the controller uses our fake set of in-memory data rather than connecting to the real database.
As we saw in the Test Explorer, both tests are run successfully, independent of the database.
Summary
In this article we saw basic unit testing of MVC4 application. Dependency Injection was used in the controller to remove the database dependency. For more information about Dependency Injection, please check the following link.
http://martinfowler.com/articles/injection.html
In this article we will see how to Unit Test a MVC4 application with Dependency Injection.
Steps
The MVC application we will be using is already explained to a previous article. As explained in the previous article, we have a "GuestBook" controller as explained below.
One of the issues with the current implementation of the "GuestbookController" is that it directly instantiates and uses the "GuestbookContext" object, which in turn accesses the database.
The solution to this is to decouple the controller from the GuestbookContext. Instead of accessing the "GuestBook" data directly from the DB, we will create a repository as below.
A concrete class that implements the "IGuestBookRepository" interface method is created as in the following:
Note that this concrete class has the direct reference to the "DBContext". Let's integrate this repository into the "GuestBook" controller.
Before making any changes to the "GuestBook" controller, remove the DBcontext code and create a local variable to hold the "IGuestBookRepository" interface instance.
Rather than instantiating the GuestbookContext, we now store an instance of our repository within a field. The controller's default constructor populates the field with the default implementation of the repository. The second constructor allows us to provide our own instance of the repository rather than the default. This is what we'll use in our unit tests to pass in a fake implementation of the repository.
The actions in our controller now use the repository, instead of using the LINQ queries that will do the direct DB call.
All these changes are for removing the dependency with the database and we make the existing application work without any issues.
Create a simple fake repository as below that implements the "IGuestbookRepository" interface.
Let's start to create a new unit test project from an existing application.
Create a new test method that is using our Fake repository:
Create a complex test method like the following one, it asserts that a list of "Guestbook" objects was passed to the view.
Both tests make use of the fake repository "B". By passing it to the controller's constructor, we ensure that the controller uses our fake set of in-memory data rather than connecting to the real database.
As we saw in the Test Explorer, both tests are run successfully, independent of the database.
Summary
In this article we saw basic unit testing of MVC4 application. Dependency Injection was used in the controller to remove the database dependency. For more information about Dependency Injection, please check the following link.
http://martinfowler.com/articles/injection.html
No comments:
Post a Comment