I realize this is a duplicate of about 20 different posts, but none of them are specific to MVC4, and none that I've seen really answer all of my questions. So far my first foray into the world of TDD has been frustrating to say the least. Most of what I've tried to do seems incompatible with MVC 4 or next to impossible without using poorly documented third party libraries I don't quite understand yet.
What I want to be able to do, is write a tests that will test my Controller Actions, The Model they're passing and The View the action is sending the model to. I want to test if the view exists, I want to test if the model being passed is the right type for the view, I'd like some way to test if it will process properly. I also want to be able to test my routes. And testing Authentication filters?
I want a way to unit test ASP.Net MVC that will leave very little to chance.
Testing the Model output of an Action seems easy enough, but testing the views has been next to impossible.
So here's my list of questions:
Once I test the action and get the action result, how do I test to see if the view it wants exists?
How do I test my routes?
How can I test to be sure my views are being processed properly?
What is really "best practice" for THOROUGH unit testing of ASP.Net MVC 4?
How do I unit test forms authentication?
How do I unit test Action Filters?
I'd prefer to use the built in Visual Studio test projects, but if I must use NUnit, I must. I just need to make sure it gets done properly.
Thank you in advance for your responses.
EDIT: I also couldn't get NUnit working with my MVC4 app because of some incompatibly with the version of .NET one of the assemblies was compiled in.
Making sure a view exists
http://haacked.com/archive/2007/12/17/testing-routes-in-asp.net-mvc.aspx/
http://blog.davidebbo.com/2011/06/unit-test-your-mvc-views-using-razor.html
see below
How can I unit test my ASP.NET MVC controller that uses FormsAuthentication?
How-to test action filters in ASP.NET MVC?
no. 4: This is a hard question. How does one test anything thoroughly? Personally, I don't really test the views, other than with the 3 major browsers and my two eyes, as it's hard to test a website and all it's components without actually using it. You have JavaScript firing, CSS stylizing, and it looks different across different browsers. So, to me, it seems like testing the view that thoroughly is a minor part of the overall usability of your site. If you're developing a simple table based report of financial data, test that data hard. If your view is a the base for a fancy Ajax site, maybe don't test the HTML so much as the experience. I know it's not an easy, cut-and-dry answer, but the acceptable level of coverage always involves trade offs.
Related
Here's the situation. We're adding a new application to our suite of webapps based on WebForms and so I felt this would be the perfect time to introduce MVC.
I did all the research about intermingling the two and got the project all set up using an Area that uses MVC routes while the rest of the (visual studio) project runs with web forms the way it's been running.
Master pages were converted to Razor layouts, not too bad because there was only one master page that was shared between every application.
The problem I've run into now is reusing user controls. We have dozens of custom user controls, many of them fairly complex, that are reused throughout all of our applications. Most of them (especially ones that would be difficult to port) do a fair amount with ViewState and postbacks.
If it were just a matter of rewriting these in MVC, the one time cost would be less than ideal but not terrible. But since the existing apps need to be maintained and updated as well, it seems like maintaining 2 versions of the same behaviour using entirely different paradigms would be a huge drain on productivity.
My gut says there isn't really a good solution and we may have to abandon the idea of going to MVC for this project and stick with webforms, but I wanted to see if the SO community has any insight on what to do in this scenario.
If you have the budget to rewrite those server side controls using the MVC paradigm that would be the best way to go. If not, you could still embed them into existing classic WebForms pages and which would communicate with the new MVC application using standard HTTP/HTML techniques: form posts, sending ids through query string parameters, iframes, cookies, HTML 5 storages, etc... One thing's for sure though: try to avoid putting those server side controls in your MVC views. You will end up with some hybrid application that is neither proper ASP.NET MVC nor a proper WebForms which would be a disaster.
Personally I had to do this same migration multiple times and I didn't bother mixing classic WebForms with MVC in the same application using Areas or some other techniques. At the end of the day it might turn into a nightmare trying to make those two exist together. It's always one of the two: I have the budget and I rewrite from scratch properly or I don't have the budget and I do the new stuff properly using ASP.NET MVC and try to interact with the existing application.
I find it easier to simply start a separate MVC application which depending on the interaction I am looking for would use different methods for integrating functionality from the existing WebForms application.
I am not quite familiar with the complexity and details of your scenario so it is difficult to provide an objective answer but the possibility of continuing to write new code based on the existing WebForms server side controls and not doing any MVC at all for this project might also be a good solution. Writing a new application on ASP.NET MVC just for the sake of it might not always be the best choice.
I'm working in a Banking Online Platform written in WebForms and I'm wondering if the same could or should be written in MVC.
I've read a lot on MVC but i didn't tried yet but i must ask a question for the experts.
Every transaction has a 3 Stage Process where the users input the data, review the data and gets a 3rd step where get's the confirmation. I currently have 40+ processes like this. The way i do it? Single ASPX with MultiView.
How can i do the same in MVC? Would i have 40+ x 3 Views (120+ aspx) ?
Thank U all.
The same can be achieved in MVC by using partial views.
MVC has full control over the rendered HTML and JavaScript frameworks is much easier to implement. It is also a lot more easier to write unit tests.
It is also 'lighter' in the sense that it does not have any View State events (which is the thing that makes Web Forms big when working with big data)
Asp.net MVC 3 preview 1 was released at the end of last month. Are there any new features you are excited about or any features you would like to see before it is fully released?
Full support for Controllers with Generic Parameters
public GenericController<SomeType> : Controller
Generic controllers are quite possibly the greatest MVC timesaver if your doing a lot or business CRUD. There are so many similarities between the Add methods of almost every MVC project that it makes sense to abstract these operations out in a Controller that fits all scenarios.
Right now its a little hacky to create a generic controller. The MVC engine always gets the name wrong (GenericCo vs. Generic) and without full support plugin and libraries that interact with controllers just fall over when they encounter a generic one.
Make Dropdowns easier to work with
As a professional MVC tag watcher I've noticed that working with dropdowns is one of the most repeated questions on SO. The amount of Dropdown questions is a strong indication that something should be done to make it easier or less ... complex?
make checkbox list easy to work with
add T4MVC to the official release
add official helpers for OData
support one javascript library either MS Ajax or jQuery(preferably)
I wish they can add something to help developer to migrate their previous ASP.NET WebForms application.
Seems like every project I'm on uses a Model View Controller architecture, and that's how I roll my own projects. Is there an alternative? How else would one create an application that has persistent storage and a user interface?
MVC has been around for a while. It's a time tested and proven pattern. Many frameworks leverage the MVC Pattern. Martin Fowler has deconstructed the MVC into: Supervising Presenter and Passive View.
Architect Christopher Alexander said it best:
Each pattern describes a problem which
occurs over and over again in our
environment and then describes the
core of the solution to that problem,
in such a way that you can use this
solution a million times over, without
ever doing it the same way twice.
I'm not sure why you would want to move from MVC. Is there a problem you are encountering that MVC does not eloquently solve? To give you a better answer we need to know more about your problem domain.
Things to take into account when considering patterns/architecture: If you are building something with a Myspace type architecture you'll need a robust architecture (MVC). If you are creating a simple crud interface via the web - almost anything will do.
For .Net Web forms (I am assuming web, since you didn't say thick or web client) which is not MVC, it was a nightmare maintaining them. Web Forms applications that lived more that a couple years tended to become big balls of mud. Even then developers discovered ways to use MVC with web forms.
Ironically, the lack of MVC architecture in ASP.NET web forms was one of the driving complaints that lead to the development of ASP.Net MVC framework.
From experience if you don't use some MVCesk approach, your solutions become hard to maintain and bloated. These applications will die a slow painful death.
If your solutions are small one-off projects, the by all means throw something together. Heck there are tools that will generate everything from the screens to the data access layer. Whatever works to get the job done.
Classic CRUD apps built using tools like VB6 and Delphi have user interfaces, persistent storage and don't use MVC. Most of them used data aware controls linked directly to database fields
Couple of links comparing various MV* patterns which might be useful:WPF patterns : MVC, MVP or MVVM or…? & MVC, MVP and MVVM
Look into MVP model view presenter.
User interface is View and an application will always have a model and the bridge between the two is Controller. The whole MVC is nothing special as this is how the things will be always.
At the most you can get rid of Controller and have your view talk to your model but you loose the flexibility.
I've developed an alternative to ASP.NET MVC. You get the same loose coupling and separation of concerns but the difference is in how you go about building your projects.
I have a couple of videos on my blog, source code for the framework, a sample project and a few VS.NET add-ins (New Project item, New Builder and New View).
Builder for ASP.NET
Some key differentiating Features are
1. Templates are just html - no code mixed with templates
2. Templates are thus reusable across views and Web site designers can design templates in their design tool of choice
3. Strongly typed code (no ViewData and stuff) so you get intillisense, compile time checking, F12 navigation etc.
4. You build pages as compositions of views rather than an inside-out approach
5. View can be treated as "real" classes.
6. Everything is complied so no run-time compilation
Quite a few other differentiating factors as well.
In theory :
MVC is a proved technology and yada-yada-yada, and it is ideal for websites.
But in a real case:
A serious project that use MVC required a framework, hence you are following a framework with all their limiting and restrictions. So, at this point, the specific implementation of MVC is rule and not a simple "guideline".
Also MVC fail miserably for websites when it is about to connect to the model other than simple POST/GET, it fail with xml asynchronism and it fail with ajax. (*)
(*) exist some patch but a design must be clear and functional and if you need to "patch it" then it is neither clear nor functional.
Personally i think that the main problem with MVC is that it put so much effort in the Controller, where most project use not more that 5 lines for the controller part.
ps: Most "well done" MVC projects are 3-tier project.
ps2: MVC excluding some framework, is just a buzzterm, IS NOT A SERIOUS TERMINOLOGY and it is reflexed in the group of "interpretation of mvc".
So I know that unit testing is a must. I get the idea that TDD is the way to go when adding new modules. Even if, in practice, I don't actually do it. A bit like commenting code, really.
The real thing is, I'm struggling to get my head around how to unit-test the UI and more generally objects that generate events: user controls, asynchronous database operations, etc.
So much of my code relates to UI events that I can't quite see how to even start the unit testing.
There must be some primers and starter docs out there? Some hints and tips?
I'm generally working in C# (2.0 and 3.5) but I'm not sure that this is strictly relevant to the question.
the thing to remember is that unit testing is about testing the units of code you write. Your unit tests shouldn't test that clicking a button raises an event, but that the code being executed by that click event does as it's supposed to.
What you're really wanting to do is test the underlying code does what it should so that your UI layers can execute that code with confidence.
Read this if you're struggling with UI Testing
Manually test UI stuff where benefit to cost in automating it is minimal. Test everything under the UI skin ruthlessly. Use Humble Dialog, MVC or variants to keep logic and UI distinct and loosely coupled.
You should separate logic and presentation. Using MVP(Model-View-Presenter)/MVC (Model-View-Controller) patterns you can unit test you logic without relying on UI events.
Also you can use White framework to simulate user input.
I would highly recommend you to visit Microsoft's Patterns&Practices developer center, especially take a look at composite application block and Prism - you can get a lot of information on test driven design.
The parts of your application that talk to the outside world (ie UI, database etc.) are always a problem when unit-testing. The way around this is actually not to test those layers but make them as thin as possible. For the UI you can use a humble dialog or a view that doesn't do anything worth testing and then put all the logic in a controller or presenter class. You can then use a mocking framework or write your own mock objects to make fake versions of the views to test the logic in the presenters or controller. On the database side you can do something similar.
Testing events is not impossible. You can for example subscribe an anonymous method to the event that throws an exception if the event is thrown or counts the number of times the event is thrown.