Ive been learning MVC2 and MVVM lately and I think it works like this.
ASP.NET MVC2 - Can test the whole web site using unit tests
ASP.NET MVC2 + jquery web service calls - Can no longer just use MSTest unit test. What is the MS product to test the javascript side?
ASP.NET Webforms - Unit Tests are near impossible when the coder doesnt create the Webforms site with Testing in mind. Therefore Asp.NET web performance tests are the closest thing to testing that is realistic. Coded UI Tests are too trivial to really be useful for things like ASP.NET validators.
ASP.NET Webforms + jquery web service calls - Can only unit test the web service calls. Cannot use Web Performance tests because of javsscript calls. Need some sort of javascript testing framework.
Silverlight - No tests. Maybe Coded UI Tests.
Silverlight MVVM - Use silverlight unit test framework to test ViewModel similiar to MVC.
Silverlight MEF - How does MEF affect testing scenerios if at all ?
Is this accurate? Is there anything I am missing ?
I am trying to make a argument to the people in charge that we should use MVC over Webforms so that we can create automated testing. As it is we are doing Webforms all in one project and impossible to test so people just test off of manual scripts :(
Rather than specifying the reasons why you should use MVC over Webforms, I'd take a step back and sell the management team on why you should use unit tests. After that's sold you have a case of saying that MVC would allow you to do this more efficiently than webforms.
Are you looking at going the full TDD route, or just creating tests after? I'd highly recommend going down the TDD path even though it does have a steeper learning curve and will lessen your productivity while you are learning it.
Since you are already looking into testing, you probably know most of these, but I'll re-iterate some of the benefits:
Less defects get through to QA.
Tests can be created for issues that QA and customers find.
Designing for testing creates a more loosely coupled application which tend to be more maintainable.
Increased developer confidence when making changes leading to sustained productivity as the application code base matures.
Tests are great documentation for new developers joining the project, as they can see what's trying to be achieved.
Note: the cost of fixing a defect that has made it through to production can be up to 80 x the cost of finding and fixing it in the development and QA process (I'll try to find my source for that figure).
Unit testing is only one piece of the puzzle though, you'll also want to look at using a Continuous Integration server such as CruiseControl.NET to automate your builds and tests. This will make sure that everyone keeps the build in a working state.
For an existing Webforms project you might also want to look into the Web Client Software Factory. I've found it to be very useful for migrating legacy webforms apps over time, though it's a little more convoluted than MVC2.
I don't know about other technologies, but I can talk about using Silverlight with MVVM pattern. Using MVVM pattern along with command pattern, we have been able to unit test all of our C# code. I mean barring xaml code, we have a very high code coverage for our C# code. We actually use a modified version of MVVM wherein we also use a controller. If you ensure that you have no code in code-behind files, you can simulate button click/other such UI events. This is very useful for integration tests. We have found out that our pattern of MVVM along with controller and using command pattern facilitates unit testing.
Related
I need help / advice on the below scenario.
We are planning to develop a web application which can handles millions of transaction per week with the below technologies.
1. WF4 for Work Flow definition / Business logic etc..
2. WPF for Application Design
Question 1:
We are also considering MVC3. Is it really necessary to use MVC3 with WF4 or we can go ahead with the traditional WebForms? We have absolutely no idea and we are confused. Ultimately we want to increase the developers productivity time by decrease the coding time.
Question 2:
Is it possible to use MVC3 with WF4? If so, please provide me some resources. There is very limited resources for this combo.
Your help is appreciated.
Performance in MVC is going to be better 'out of the box' so to say because of the lack of viewstate and the ability for lightweight responses using JSON.
If you are looking at a high performance site and aren't sure what to use - I would recommend MVC. There will be a slight learning curve but in the end I think you will be thankful you did. Unit testing alone is so much easier.
re workflow:
Since code can trigger off a workflow, you absolutely can use it. Just call your workflow, there's nothing special there.
The first google result for running from asp.net
http://msdn.microsoft.com/en-us/magazine/cc163623.aspx
You can expose your workflow via a service, call directly, etc.
How to write unit tests, integration tests for asp.net web applications ( not an MVC application). Can some one give me help to start up. i am new to this..
Personally I think all this unit testability hype is totally overblown. You can test an ASP.NET application (that is well architected) very easily. We used to call it a "smoke test". Every action that can be done in the app is tested by QA with the idea of breaking something. Usually they will succeed, and the developers get to work to fix it. Just my 2 cents.
A lot of the unit tests I've seen simply represent somebody who can't see the forest for the trees writing a bunch of extra code and layers of stuff that may not be that relevant.
I'm developing a website in asp.net webforms with 3 layers; UI, BLL and DAL
The website is already developed, but i like have more control about the unit tests of each form
Pass specific values at specific inputs for i see, if application survives or not.
I already study about NUnit but in webforms in UI layer how can apply these tests?
What i wnat is get some way to test UI (validations) without have to access to the BLL as i was an user.
I'm trying to add the Unit tests to my app but i not sure how to do it!
somebody can help my small-bigger problem?
You can add unit test to your UI using one of these tools
http://watin.sourceforge.net/
http://seleniumhq.org/
With both tools you can generate C# or VB classes that can be used by NUnit.
IMHO, UI test are not as reliable as the common unit tests. Bacause timing conditions you may randomly find that some test will fail.
I used both tools and I recommend selenium mainly because you can generate test that can be run against any browser.
Here an example how to use Watin with NUnit
http://www.codeproject.com/KB/applications/SimpleUITestHarness.aspx
And here a guide how to use Seleniun with Nunit
http://www.lostechies.com/blogs/agilecruz/archive/2009/02/10/how-to-configure-selenium-rc-for-use-in-c-nunit-tests.aspx
If I understand your question correctly, you're asking how to automate testing a WebForms UI. If I misunderstand, please correct this understanding.
Frankly, I don't think there is a good answer out there for this. There are two options, however, that work okay:
Visual Studio Test Edition
Telerik's Web Testing (both a free version and a version with a cost)
Why should I use ASP.NET MVC with TDD?
Which are the advantage of TDD? Why it is suitable for MVC to use this kind of approach?
ASP.NET MVC offers an alternative to traditional WebForms development. It gives a clear separation of concerns in the application which makes code easier to test. In contrast to WebForms, in ASP.NET MVC infrastructure classes such as HttpContext are abstracted and could be mocked in unit tests to simulate request handling. You also have much more control over the generated HTML which is a good thing in case you want to comply with standards.
Due to the separation TDD could be applied. In this iterative process, unit tests are written to validate the code against a list of specifications. In the first stages of development writing unit tests might seem to slow down the process but as the code grows its benefits become clearer as you no longer need manually test every aspect of the application once you modify or refactor something.
Testablity and TDD
Compared to ASP.NET testing (unit testing) is much, much easier.
Plus on a side note, I enjoy having full control over the HTML output to the users browser. Rather than the mess that ASP.NET auto generates for you.
ASP.NET MVC is a joy to use in comparison.
They are a natural combination :)
ASP.NET WebForms is not friendly to TDD. MVC makes it much easier.
Asp.net mvc with TDD:
This walkthrough shows you how to develop an ASP.NET MVC application in Visual Studio using the test-driven development (TDD) approach. MVC was designed to enable testability without requiring dependencies on a Web server (IIS), on a database, or on external classes. (This is in contrast to unit tests for Web Forms pages, which require a Web server.)
In this walkthrough, you will create tests for an MVC controller before you implement the controller functionality. You can write tests before you have a controller. The advantage is that compiler errors in your unit tests are then a first-level form of unit-test failure. The emphasis is on how to design the intent of the controller by writing unit tests before implementing the controller itself, which is an important aspect of the TDD philosophy.
Test-driven development:
Test-driven development (TDD) attempts to resolve this problem and produce higher quality, well-tested code by putting the cart before the horse and writing the tests before we write the code. One of the core practices of Extreme Programming (XP), TDD is acquiring a strong following in the Java community, but very little has been written about doing it in .NET
**one advantage according to my experience is that:
When You are refactoring code ..it will TDD help to find impact of change on other modules or Codes.
Other advantage is if you are developing application with TDD with proper test methods application is more stable(stable means minimum bugs) than simple development.
SOLID is a set of design principles that we constantly think about and try to follow when writing good production code.
SOLID stands for (Single responsibility principle, Open-closed principle, Liskov substitution, Interface segregation and Dependency Injection).
What makes TDD great when writing an ASP.NET project (or any projects for that matter) is that by following TDD you automatically create code that follows the SOLID principles.
SOLID code will make your code easily changeable, less brittle, easy to maintain and flexible. = Great code.
I recently heard a discussion in which TDD was the hot buzz word. Now according to one speaker, in order to test your behaviors you need to use MVC but on the other side its been said that TDD is an approach which can be adopted in any environment (as the discussion surrounding ASP.NET MVC or Web Forms). Another speaker claimed that if you put your behaviors in library or models then you can just test your repository or services in TDD and hence don't need to worry about testing HTML. How much TDD should cover in case of Web GUI testing or is it worth the effort?
I know sometimes we use the "next best thing" and carry it to the extreme, but it doesn't really benefit real development scenarios. So can TDD be applied to the UI?
EDIT:
I agree with you guys and that's also how I feel: if you really do TDD then you don't need to test your WEB UI front end, since the data that you're providing to it should be under your business/services/repositories layers which can be tested without a UI. So if you program your Web Forms application in such a way that your operations/behaviors are tied in with server side calls (like button click events although in my case they can be tested by calling lower level operations) you can have TDD in Web Forms. Thanks for your answers
I will be bold enough to say that if you need to unit test your GUI in order to get business logic, or integration testing done, then your design is lacking a clean separation of concerns. Both MVC and MVP are patterns that offer a clean separation of concerns so your UI can focus solely on presentation logic.
You do have both options in ASP.Net using either ASP.Net MVC, or WCSF (an MVP implentation using web forms).
That being said, you should still do GUI testing, but you have no need to do all this manually. Selenium Server, and Selenium Remote Control offer ways to do automated testing through the UI.
I agree with Josh here. Just getting going on SO, though, so I can't vote it up.
It should be noted firstly that testing your GUI is not unit testing. With clean separation of concerns, as Josh advocated, the GUI contains no business logic.
The logic that requires testing is encapsulated in one or more discrete libraries (or possibly in simple MVC controllers).
TDD refers only to logical code units, and one hallmark of solid TDD practice is that all of your logic code can be written and tested without any UI at all. In fact, tests are often written before the classes they will test. Once code is complete and all tests pass, the UI can be added to utilize the API hooks you've built, and that UI can be webforms, MVC, WPF, winforms, etc.
Testing on the UI that you'll do with a product like Selenium has more to do with acceptance testing or possibly integration testing.