I'm just starting my first MVC3 application, and I'm not sure how to unit-test it. I was planning to break out helper classes (static helpers, usually) into a separate assembly, as well as model classes, so that I could test them with NUnit.
So I'm OK on helper classes; but how do I test model classes (considering that they're annotated for NHibernate and tied to the database), and how can I test my views and controllers?
What are the specific tools and techniques I need to test NHibernate-bound models, as well as ASP.NET views and controllers? I'm not sure. NUnit only solves some of the problem.
Edit: Here's some samples of code -- I'm not on my dev machine right now, so I don't have real code to show-case.
Models: Anything from the ActiveRecord documentation
Controllers: The standard HomeController from the MVC3 documentation
Views: Any strongly-typed view (let's say Create) generated from the right-click context menu (Add > View)
Specific questions:
How I can test saving models without actually saving to the main/production database
Scope for testing views; should I simply test fields exist? What about validation error messages?
Controllers: scope for testing. Should I test that actions touch and deform database data as expected (eg. /get/id gets that object; /delete/id deletes that object)?
You can get there by various kinds of tests, but you need to apply them wisely depending on what you are going to test:
Use unit test to test your controllers, or your business logic, without hitting the database.
Use integration testing by running on an in-memory database (which NHibernate supports and is easy to setup). You can make sure a scenario actually works, e.g. using a valid scenario, all the business logic is working, your controller pass the data to persistence mechanism and it goes correctly into the database.
You can use UI Testing using frameworks such as Selenium but only do that where really needed, because it is not easy as two previous types of tests, and would become hard to maintain and fragile.
It is a best practice to keep your view (UI) thin, and test other layers behind the UI, as testing the UI probably does not worth all the hassle.
Related
I'd like to create a highly maintainable code, with unit tests.
I have read the best practices so directories are organized as per best practice, with just one bundle named AppBundle, and I'm using annotations.
I have an issue with business logic. I've read that I should not put business logic inside controllers. As the vast majority of my code was not meant to be reused I put the logic inside the controllers. Yesterday I read here that "logic should live in the controller unless you’re going to unit test it or until you need to re-use it" and this made me faint: am I not going to unit test if I put my logic inside controllers?
I understand that "controllers should be as lean as possible, with few lines of code to glue stuff together". But what about forms? A form often has a logic like "display the form, if it's valid do something and display another page". Now if I'm going to put the form creation and logic inside a service (or a model?) I'd have to put the page render command inside that, so basically the controller would be 1 line, with all the rest inside the service, and the actual decision of which page to display would be done inside the service, not the controller itself...so what's the point of a controller, just the routing?
I really need to understand this before proceeding (i've already developed 3 months on this and I'd have to rework a lot, but better now than never)...
Thank you!
EDIT: some additional considerations to address some of the comments below.
I have a clear understanding of how forms work in Symfony, with the creation of the form and it's management with the "isValid()" in the same place.
Let's imagine the following controller which performs the following operations:
get the current customer from security context
queries the DB to get the field $user->getIsBillable()
if the user is not billable
queries the DB to find if someone else is paying for him
else //the user is billable
create and manage form1
if the user is not billable but there is someone who is paying for him
check if the license is active (I have to call an external API)
if the license is not ok
redirect to a page to update credit card info
if the user is not billable
create and manage form2
else
create and manage form3
render the license management page with all the necessary forms created
What would be supposed to do? Put all this stuff into a service which would return the forms (or null if a form is not created)? Consider that in the "is valid" of some of the forms I render the same page with simply updated info. Or should I create a service foreach of the forms creation and keep the logic in the controller?
You should keep your logic outside the controllers in order for your code to be more reusable and to reduce code duplication.
The best practice is to have your business logic registered as a Symfony service instead.
The controller should be as lean as possible as it only handles the view and accessing your services to run business logic functionality.
Using services will make your code more reusable and it will be easier to write unit tests for each part of your code.
Forms are handled in a different way in Symfony2 and you should read more about it: http://symfony.com/doc/current/book/forms.html
Like most php frameworks, symfony2 has its problems.
Turns out symfony2 best practices are not always best practices. But in most cases symfony allows for loose coupling and proper dependency injection, it just doesn't tell you in the "book".
For example a very important topic: http://symfony.com/doc/current/cookbook/controller/service.html
I usually have my form types as services, my controllers as services and other services for the business logic. My controller actions are ideally around 3-5 lines of code. Sometimes when handling a file upload they will be slightly longer though.
You can unit test your business logic services, but for your controllers and forms you will need some sort of integration testing, or use heavy mocking.
I understand that "Selenium" is a good tool for testing such things, I haven't used it yet.
One thing that I would like add to other answers provided there to you is that Unit Test is different from Functional Test.
Unit Test
You need Unit Test when you want to test individual "unit" of code (such as method in a class)
Functional Test
You need Functional Test when you want to test a "suite" of functionalities (like many methods interactions, db interactions, web services and so on)
Recap
Ideally you want to write Unit Test(s) for a class that contains heavy business logic whereas you need Functional Test(s) for testing whole controller (so a page is render with all class interactions and db ones, the page is render, the page is posted and so on)
The best approach, to me - and it's only an opinion of a devel that tried as today to understand testing from a newbie point of view - is to mix each other: with Unit Test (and isolation, of course!) I'm sure that (simplifying) every input that I provide to my method will return the correct output, while functional test will help me to test the whole thing and interactions.
Answer
So, returning to your question - that seems wider that at first look could seems - a good way to procede is to keep all business logic outside controllers (even if you're sure [and to me you'll never be sure enaugh] that code you put in will be never reused elsewhere) by defining services (as said in other answers). Then you will do some unit test(s) onto your services and after that you will probably need some Functional Test(s) to check that all "the glue keep things together correctly".
I don't know if I'm missing something (it's likely). Just to be more complete, I will attach my older question on Symfony2 (I was studying it and MVC pattern at the time)
Structuring your code to be clean and maintainable it is a very hard stuff, I suggest you to start studying the SOLID principles than having a superficial understanding of MVC:
Single Responsability Principle - SRP
Open/Closed Principle - OCP
Liskov Substitution - LSP
Interface Segregation - ISP
Dependency Inversion Principle - DIP
How to do TDD/BDD with asp.net 4.0 Web Forms? I have an existing website that has very large scale and we dont have any test with each change in database we have to guess what will break? I want to introduce unit testing please give me pointers?
A lot will depend on how your existing codebase is structured.
It can take a lot of work to retrofit Unit testing and especially TDD into a legacy project. Typically you'll find database and business logic residing in the code behind file of the web pages.
Use of interface types are your friend here as Visual Studio can generate Interface classes automatically for you. (Place the cursor over a class name, right click, select refactor and extract interface)
I would work towards separating your database code into a class library project of it's own. You can then specify the public interface through which the business logic etc can access the database. All other code should treat the database repository as a black box.
Create a factory to make your repository (based on that Interface), have it create a test type and a live type. The live type will link into your current database code. The test type will just return hard coded values. You can write tests using the live database, then you can write tests for the "test" database in a TDD manner.
Once they both match (all tests pass) any new database functionality is added by writing the test that runs on the "test" database first and then on the live database.
Remember all code should only use the Interface to the database not an instantiated live database class.
Once you've got the hang of the process you can delve deeper (if you wish) within the database code, but I would say that following the same process in separating and testing business and UI logic is more practical on a legacy project.
You may find that a pragmatic approach is to only separate out functionality following the process that I've described as you go to add new code. In other words before you add new functionality, separate out the code as described writing the tests that show that it passes (live and test version) then alter or add test for new functionality using whether the test passes or fails to guide your coding.
If covering all bases you want a test for failure, test for pass and maybe a test for exception scenario.
Good luck. It's not a job for the faint hearted (having had to do it many times in the past).
We're using MVC, Entity Framework 4.1 Code First, SQL Server in our project.
Please share your experience: how do you unit test your data service layer? By data service layer I mean services supposed to be run by MVC controllers that have some kind of DbContext derived class declaration inside, so that they depend on this EF DbContext, and encapsulate some business\data logic to fetch and store the data.
After reading few articles and posts, I incline to use separate database to build unit/integration tests on, and I prefer to use in-memory (like SQLite) rather than SQL Compact. However I'm not even sure if it's possible, if you have such an experience, could be please share few lines of code to show how you achieve this.
Unit testing means testing unit = no database, no external dependency, just testing single testable unit. Once you want to involve database you don't unit test any more - you are doing integration testing.
I wrote multiple answers about unit testing / integration testing of code dependent on EF. The last one is here. So if your service layer creates linq queries on context you cannot reliably unit test them. You need integration tests.
I would use the same database as you expect to use in your real code. Why? Because mapping and behaviour between database provides can differ as well as implementation of LINQ. Also in case of SQL server you can use special EF features which don't have to be available in SQLite. Another reason is that last time I checked it, SQLite's provider didn't support database deletion, recreation, etc. which is something people usually want to use for integration tests. Solution for that can be Devart provider.
I don't use a separate database at all. In fact, my Unit Tests don't use a database at all.
My strategy is to create IEnityRepository interfaces for the DB Entities (replace Entity with the actual name). I then pass those to the constructor for my controllers.
During Unit Testing, I simply use a Mocking library to pass mock implementations of the repositories that I need and have the return some set of known data that I can use in the Unit Tests.
I currently have a project I've started with EF4, and am going back and adding in unit testing after the fact. I am using the EF4 POCO T4 templates with my model (database) first context. I am using generic repositories for my DAC logic, and unit of work pattern for persistence.
However, I'm running into some issues understanding how to mock up the ObjectContext/ObjectSet. I looked at using the FakeObjectSet<T> sample from this article, but it still leaves a few things out, such as auto-incrementing identities and transaction rollbacks.
So, I'm trying to find a good EF design that will still be fully unit testable.
My question is, does EF4.1 DbSet solve a lot of the issues w/ unit testing EF4? Are there any good comprehensive articles for designing EF4.1 solutions that are fully testable?
Also, keep in mind that I need a model-first solution.
Thanks in advance.
Fully simulating behavior of mocked layer is not point of unit testing. The point of unit testing is believing that mocked layer simply works. Unit test verifies the tested method not the mock. You will just verify that correct method on the mock were called and perhaps you will set up some callbacks for modifying passed data if your business logic expects some values. Example:
You have a business method inserting the record to the database and using the entity and its Id after insertion. The IObjectSet mock will be configured to:
Set expectation that AddObject was called only once - you can set the expected instance in the verification
You can define callback for AddObject to set Id to some value and use it later in the test
DbSet will not make any difference - it is just wrapper around ObjectSet with similar behavior. In my opinion there is no efficient way to make mocks behave as real EF. The effort needed for creating mock with behavior simulating EF + database will be much bigger then effort for your whole application! That will not be mock anymore it will be fake EF provider.
If you want to test your EF code (mapping, querying, persisting) and database behavior (like auto-increment, transactions, etc) you have to write integration tests. Here you have some related questions discussing repositories, unit of work and challenges with testing:
ASP.NET MVC3 and Entity Framework Code first architecture
Organizationally, where should I put common queries when using Entity Framework Code First?
I have a simple project, mostly consisting of back-end service code. I have this fully unit-tested, including my DAL layer...
Now I have to write the front-end. I re-use what business objects I can in my front-end, and at one point I have a grid that renders some output. I have my DAL object with some function called DisplayRecords(id) which displays the records for a given ID...
All of this DAL objects are unit tested. But is it worth it to write a unit test for the DisplayRecords() function? This function is calling a stored proc, which is doing some joins. This means that my unit-test would have to set-up multiple tables, one with 15 columns, and its return value is a DataSet (this is the only function in my DAL that returns a datset - because it wasnt worth it to create an object just for this one grid)...
Is stuff like this even worth testing? What about front-end logic in general - do people tend to skip unit tests for the ASP.NET front-end, similar to how people 'skip' the logic for private functions? I know the latter is a bit different - testing behavior vs implementation and all... but, am just curious what the general rule-of-thumb is?
Thanks very much
There are a few things that weigh into whether you should write tests:
It's all about confidence. You build tests so that you have confidence to make changes. Can you confidently make changes without tests?
How important is this code to the consumers of the application? If this is critical and central to everything, test it.
How embarrassing is it if you have regressions? On my last project, my goal was no regressions-- I didn't want the client to have to report the same bug twice. So every important bug got a test to reproduce it before it was fixed.
How hard is it to write the test? There are many tools that can help ease the pain:
Selenium is well understood and straightforward to set up. Can be a little expensive to maintain a large test suite in selenium. You'll need the fixture data for this to work.
Use a mock to stub out your DAL call, assuming its tested elsewhere. That way you can save time creating all the fixture data. This is a common pattern in testing Java/Spring controllers.
Break the code down in other ways simply so that it can be tested. For example, extract out the code that formats a specific grid cell, and write unit tests around that, independent of the view code or real data.
I tend to make quick Selenium tests and just sit and watch the app do its thing - that's a fast validation method which avoids all the manual clicking.
Fully automated UI testing is tedious and should IMO only be done in more mature apps where the UI won't change much. Regarding the 'in-between' code, I would test it if it is reused and/or complicated/ introducing new logic, but if its just more or less a new sequence of DAL method calls and specific to a single view I would skip it.