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.
Related
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.
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.e. Is MVP still the next best choice when MVC is not an option?
I thought I'd ask this here as I'm sure there are others like me who don't have the luxury of being on a green-field project and want to refactor a webforms UI to better separation of presentation from business objects...
I'm working on a legacy application tasked with adding relatively small additional requirements, enhancements, and bug fixes.
The part of the application I'm addressing here may be characterised as the UI for a set of CRUD operations over business objects that are persisted to a relational database.
The existing UI uses a MultiView control to navigate between the editing of associated business objects (one-one associations or one-many / parent-child). Yes, that's right - all on one page. Unfortunately there is very sparing use of UserControls so the markup and code-behind is hundreds of lines long.
On each View a FormView manages the CRUD over the business objects via various ObjectDataSources. Within the ItemTemplate of each FormView various server controls databind to fields or methods on an ObjectDataSource.
I'd like to introduce more separation of concerns and get some of the reams of code out of Page code-behind.
My research so far suggests to me that I might consider:
Use a flavour of Model View Presenter; more specifically - use an ObjectContainerDataSource from the Web Client Software Factory to make it easier to bridge between the current UI and a set of new Presenter classes.
Build again from scratch with an MVC framework (not an option).
Leave well alone; an MVP pattern is only justified if I need to re-use my Presentation in different UI scenarios?
If I settle with (3) I'd still like to know how to start refactoring towards better separation of presentation.
What would you do? any other ideas gratefully received...
Here's some more background for anyone who's interested:
The domain is in pharmaceutical research but that's fairly irrelevant and you can think of it as pretty typical line-of-business - user configuration of a family of settings that form the operating conditions of another part of the application.
The business object layer has already been built in a very consistent manner. Although I may not like it, I can't neccesarily justify changing it. Each object is it's own Repository / Data Access Object in that there are static methods for 'get by ID' and 'get list by criterion'. Where possible common operations are implemented in an abstract base class. Each business object delegates the data access work to a Data Access Layer that makes use of ADO.NET 2.0 Provider Factory mechanisms to remain relatively abstracted from a concrete Provider. In this respect it shares a lot in common with any app that uses the Data Access Application Block from the Microsoft Enterprise Library.
There are fairly exhaustive integration tests written in NUnit that set up a test database from scratch so they take ages to run but at least they verify that stuff works as it should (at some point in the past anyway ;-). There is almost no true unit testing in place (yet).
WebForms now has an emerging effort in the form of the ASP.NET Web Forms MVP project
"...there are still a host of
compelling advantages to ASP.NET Web
Forms.
The ASP.NET Web Forms MVP project is
... an approach that facilitates
separation of concerns and testability
whilst maintaining the rapid
development that Web Forms was built
to deliver"
Rob Conery has concerns that this may be a wasted effort and an unneccesary distraction now that we have MVC but at this stage I still think the source code is worth a look...
http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx has a good example of doing MVP with webforms. The advantage is not just that your UI is decoupled from BL - the real treat is that you can write tests for the code.
I'm thinking about going into the ASP.NET MVC scene.
I've seen the videos at http://asp.net/learn, but they havn't impressed me.
So can you answer me, what makes MVC "so impressive", and why does it make life better and easier?
ASP.NET MVC is much more in tune with the technology on which it is layered. ASP.NET Forms attempted to pretend that there was a nice fat stateful infrastucture as there is in a standard WinForms app. However HTTP and Web servers do not like fat stateful applications.
ASP.NET MVC allows for a separation of concerns. The request is processed by a controller not a "Web Page", it chooses how to respond and what UI is needed to present that response. The controller builds the set of structured data needed by its choice of view then hands over that data to the view.
This division allows much easier testing, the view is merely a means to present what should be a complete well munged chunk of data. Its way easier to build a test for something which takes structured data in and responds with structured data.
ASP.NET Forms is almost impossible to test in this way (especially without expensive tools claiming to achieve it). Hence an MVC application is easier to get right and much easier to ensure it stays right by consistently running existing tests.
Caveat: The major draw back of ASP.NET MVC right now is lack of solid documentation. I've been assured that docs are coming "soon".
Have you ever worked on a large project that had great intentions when it started but 3 years later was a complete mess?
MVC is a just pattern it can be misused the same as ASP.NET is misused. It is just harder to do.
Model–View–Controller (MVC) is an
architectural pattern used in software
engineering. Successful use of the
pattern isolates business logic from
user interface considerations,
resulting in an application where it
is easier to modify either the visual
appearance of the application or the
underlying business rules without
affecting the other.
It allows you to separate your logic in a way that makes sense to most people. While at the same time it lends itself well to testing.