What is the basic unit testing of a web app created using ASP.NET MVC and C#. I'm using MySQL as my backend database. Do I need to create a unit test for the controller class and for the Model class? I want to use NUnit framework and NMock framework. And as I read the articles for using the NMock, I should use and Interface for my unit test but my codes doesn't have interface. Do I need to modify my web app codes and add some interface or there are another ways for this?
Please advise.
Many thanks.
If you have tight coupling in your code then you will find it hard to test each part of your application in isolation, and very difficult to mock dependencies.
So if your controller depends on SomeService then extract a new interface ISomeService and depend on that. This is where using an IoC container to inject your dependencies will also help you and promote loosely coupled code.
In a typical n-tier MVC application we would unit test our data access layer, service layer (mocking the data access layer dependency), MVC controllers (mocking the service layer dependency).
I don't tend to test my views/viewmodels because they are pretty dumb anyway.
When I first started MVC I read the Pro ASP.net MVC 2 book by Apress and I'd highly recommend it (Although the MVC 3 book comes out in a few weeks). It explains how to design your site so that it can be effectively unit tested. It also uses NUnit and Moq for testing. http://amzn.to/iIfij4
Related
I'm trying to write unit tests for my new ASP.NET Web API. I'm using Ninject for Dependency Injection and would like to write the tests which help me test my API controllers/methods directly instead of using mocking feature. I'm having trouble connecting to database while running these unit tests. Is there any other way to write these tests which gets the actual data from database while testing the API.
Please suggest.
Thanks in advance.
Sorry if I am asking very basic question,
I have set of web services (developed using .Net WebApi). These services are either business layer or data access layer APIs. These APIs are either dependent on other services or database itself.
I want to write unit test cases for it. I have following questions
As business layer APIs has dependency on data access service or some other service. If I write unit test just to invoke business API then it would invoke data access API. Is this the correct way to write unit test case? or should I inject all dependency object with unit test? I think earlier one would be integration test not unit test.
Should I write unit tests for Data access layer at all? I checked this link (Writing tests for data access code: Unit tests are waste) and it says DAL does not require unit tests. Should I still write tests for data access layer. I think it would be integration test not unit tests?
Question 1:
I would say if you want to do TDD, then it's not the "correct" way, because as you said, you would be performing integration tests. Then again, maybe you don't want to do TDD and integration tests are good enough for you, but to answer the question: this wouldn't be the proper way to **unit-**test your code.
Question 2
I would say it depends what you have in your data access layer. For instance, if you implement repositories, you will probably want to write a few tests.
Save method
You want to make sure that given an entity that you have retrieved from your repository, editing some properties of this entity and persisting the changes will actually save the modifications and not create a new entity. Now: you might think this is an integration test, but it really depends on how well designed your code is. For instance, your repository could be just an extra layer of logic on top of a low-level ORM. In that case, when testing the save method, what you will do is that you will assert that the right methods are called with the right parameters on the ORM service injected in your repository.
Errors and exceptions
While accessing data, it is possible to have problems such as connection to the database being broken, or that the format of the data is not as expected, or deserialization problems. If you want to provide some good error handling and perhaps create custom exceptions and add more information to them depending on the context, then you definitely want to write tests to make sure the corrext information is propagated
on the other hand
If your DAL is just a few classes that wrap a non-mockable ORM, and you don't have any logic in there, then perhaps you don't need tests, but it seems that this doesn't happen too often, you will pretty much always have a bit of logic that can go wrong and that you want to test.
Im currently working on a project which is based on Onion Architecture . The above image Shows the Solution.
In the Infrastructure We have External Service . But the WebAPI has access only to Core .
But in the Web API project i want to access the some of the models exposed by the external services ?
How can we achieve this without adding reference to Infrastructure in the Web API .
Or we implemented Onion Architecture wrong?
conceptually you are on the right track, but the implementation isn't a hard a fast rule. to start you don't need 5+ projects at most you need 3 (web ui css/js/views, logic/controllers, code, and tests). and really you probably only need 2 (the application, the tests)
the idea of layers is conceptual, not physical. And there is not a hard and fast rule that says the layers must be completely segregated. rather the core focus of the application is what the application does. as you get into the details of how that is implemented you move to the outer layers.
in this instance you need to access data retrieved from an external service. create an abstraction for the external service IExternalServiceAdaptor. The interface may reside in the domain or server layer, but the implementation might reside in an infrastructure or outer layer where the details of how to call the external service are encapsulated within an implementation of IExternalServiceAdaptor.
If you stick with your physical separation you would have an interface in Core and the implementation in Infrstructure.
But in the Web API project i want to access the some of the models exposed by the external services ?
Actually, your WebApi project should only manipulate object defined in your Core project.
As Jason said, calls to any external services should be encapsulated within an implementation of an interface that resides in Core. And this is where models exposed by your external services will be mapped to your Core models.
Have a look at Matt Hidinger's source code on CodePlex here: http://onionarch.codeplex.com/ and check how he deals with this kind of problem, it's pretty straightforward and easy to understand.
For my ASP.NET MVC3 (new) development, I don't want to create a dependency on MvcContrib TestHelper (and thus Rhino Mocks) unless it is providing significant value. So I'm seeking to understand the current status of this helper.
The documentation says that TestHelper produces fakes for the following controller dependencies:
HttpContext
HttpRequest
HttpResponse
HttpSession
Form
TempData
QueryString
ApplicationPath
PathInfo
For MVC1 and MVC2 I can see why this was so helpful. But MVC3 started to introduce improved test "seams" which may have made TestHelper less pertinent. For example, the MVC3 Request and Response controller properties were designed specifically to be isolateable/injectable versions of HttpRequest and HttpResponse.
As I'm still exploring testability advancements in MVC3, I'd like to know how many of the other dependencies listed above have received improved isolation (or injectability) in MVC3. I'd also love to see samples of code showing what it looks like in MVC3 to create tests with fakes (stubs / mocks) for the above dependencies WITH and WITHOUT using TestHelper.
If the differences in test-writing with and without TestHelper are sufficiently marginal, then I'd prefer to forego TestHelper...which means I am then free to choose whatever isolation framework I like (MOQ or NSubstitute).
Ultimately I would be surprised to learn the MVC3 release had taken specific improved testability steps for HttpRequest and HttpResponse, but not for the other above listed dependency issues. I'm hoping someone can give a break-down of how the above items are isolated without using TestHelper.
But MVC3 started to introduce improved test "seams" which may have
made TestHelper less pertinent. For example, the MVC3 Request and
Response controller properties were designed specifically to be
isolateable/injectable versions of HttpRequest and HttpResponse.
MVC didn't introduce absolutely anything new in respect to the objects you have listed in your question in terms of unit testabaility. They were abstractions in ASP.NET MVC 1 and 2 and are abstractions in ASP.NET MVC 3. This allows you to unit test your controller actions and code that depends on them in isolation. But in order to do that you need to mock those dependencies. That's where a mocking framework comes into play. Rhino Mocks is just one possible framework. MVCContrib.TestHelper provides a really nice and fluent syntax to unit test controller actions. Personally I use it all the time. It really makes the unit tests more readable and avoids cluttering them with all kind of plumbing, mocking and infrastructure code.
Check this unit test for example: https://github.com/darind/samplemvc/blob/master/tests/SampleMvc.Web.Tests/Controllers/UsersControllerTests.cs
ASP.NET MVC 3 introduced a dependency resolver and providers which allows you to inject dependencies into many other parts of the framework other than simple controllers and thus unit test those parts which previously were difficult. For example action filters.
But in terms of the actual unit test it doesn't change anything:
you create a mock to represent some object that the subject under test depends upon and that you can control in your unit test
you define expectations on the mocked object
you call the actual method you are testing
you assert on the results
The question I'm asking is kind of subjective. I've seen twice, while exercising with real projects such as StoreFront, both Repository and Services. Sometimes they can just be folders or projects attached to the solution. But they contain classes and interfaces.
So, I'd like to know what goes to the repository and what goes to the services. So far, I was familiar with repositories (we put methods and properties in the repository to reduce the complexity in the controller). How about the services?
So, ASP.NET MVC: What's the difference in concept between Service and Repository? (Maybe none)
My question is Kind of subjective, but I'd like to make sure that I'm not missing anything.
Thanks for helping
Generally, the repository simply provides an interface to data. There is no application logic there. Services provide interfaces to application logic. Services often use repositories.