CODEWITHSUNDEEP
c#asp.netasp.net-mvcunit-testing
Actimele
Actimele

Reputation: 508

ASP.NET MVC 4 Unit testing (what i should test)

I have question what I should test, controllers or models? For example i want test user registration. Registration include some actions for inserting additional data to tables and set user status by input data.

I'm create new application with Internet template, have UserProfile class, RegisterModel class and etc. In controller code registration use WebSecurity class.

WebSecurity.CreateUserAndAccount(this.Email, this.Password);
WebSecurity.Login(this.Email, this.Password);
Roles.AddUsersToRole(new[] { this.Email }, FSUserRoles.NotValided.ToString());

All guides writing to create Repository class, but how it can be applied to code above? If I put this code to Repository, than I should test controller, and controllers will be fat. Models will be like a properties schema, repository methods will encapsulate EF methods for CRUD actions.

Upvotes: 1

Views: 985

Answers (3)

SBirthare
SBirthare

Reputation: 5137

I have question what I should test, controllers or models?

Answer is both. Every piece of code that contains any logic (not just business logic but also logic that goes in controller e.g. if a condition is true redirect to link1 otherwise link2) better be unit tested.

How much to test, is the real question that we "the developer" have to figure out.

For example i want test user registration. Registration include some actions for inserting additional data to tables and set user status by input data.

As we are discussing about unit testing, you will write test for a unit i.e. a class. In above example, you will test controller method Register() for cases where it return different output based on different conditions. E.g. if user is already exist, you will return failure with message "User name already exist".

In controller code registration use WebSecurity class.

In your controller, you would want to use a wrapper on top of WebSecurity to mock it during unit test. While writing unit test, you will setup IWebSecurityWrapper method to return different output as to test behavior of controller action.

All guides writing to create Repository class, but how it can be applied to code above? If I put this code to Repository, than I should test controller, and controllers will be fat. Models will be like a properties schema, repository methods will encapsulate EF methods for CRUD actions.

Repository pattern helps isolate presentation layer from data access layer. Again the whole idea is to be able to mock anything that code-under-unit-test uses. If your controller or model class depend on an interface like IDbContext, and discover the dependency at runtime, you will easily by able to substitute it with a mock or a stub during unit test. And that will give you bigger control over, where data comes from (in memory i.e. a collection) and where data goes, during unit test execution.

For reasons as correctly pointed by Robert Harvey in his comment above, the task of knowing how much to test, is of immense importance.

Hope this clarifies the doubt.

Upvotes: 1

Omar Elabd
Omar Elabd

Reputation: 1944

Your question was a little difficult to understand, but basically that depends entirely on your controllers and business logic. If your controller are "thin" then you can still test any routing rules. For example whether the user should be redirected based on certain circumstances. The majority of testing will be targeted to where ever the business logic resides

You'll need a repository in either circumstnace, you need a repository so you can use dependency injection to instantiate a Mock repository for your testing. This makes it so you don't actually save any data in your database during a test.

Upvotes: 0

OBR_EXO
OBR_EXO

Reputation: 600

Regarding Repositories, I assume you're talking about a Data Repository pattern? The following URL provides a good example Repository implementation for those new to the concept: http://www.codeproject.com/Articles/526874/Repositorypluspattern-cplusdoneplusright

Alot of the time when I'm writing code outside of a team I'll actually write my own DAL and tend to go with a data-first approach, I find relying on the database engine instead of the application layer will provide me with better performance in the end result, however, this increases maintenance effort of the code on an ongoing basis, not to mention requiring some level of understanding of the underlying database technology being used.

Testing can be a very intricate process depending on what you're building and who the ultimate end-user is... The answer to your question can potentially be quite broad, however, I'll stick to a generic overview on how I go about this:

Unit Testing MVC Applications (along the various stages of development):

Initial Build/Debug technical testing:

  1. Test Data-Layer Methods (database->models) either using a unit-test framework or you can even reference your DLLs and call your methods in a simple WinForms test app for instance.

  2. Test Controller Actions - can be as simple as opening /home/index in a browser, or as complex as creating another TestHarness App to call with WebClient class (if using REST/WEB-API for example).

  3. Test WebService Calls - can use SOAP-Ui if you're doing WCF or SOAP type WebServices, custom TestHarnesses for other implementations.

Controllers/Data-Access-Layer working, move onto functional:

  1. Test Views - Open your page in a browser, test the layout/CSS and make sure it displays as you desire, F12 (debug) and inspect-element options in browsers are an important tool here.

Almost Ready to Release:

  1. Test Full Interactivity - Actually use your page as the application is designed to be used. Test in multiple browsers to ensure no JavaScript/CSS rendering weirdness.

Hope that helps you some!

Upvotes: 0

Related Questions