Related
I work in a company which is primarily concerned with desktop apps not served over the internet.
Part of my value is I have a web based background and proficiencies in ASP.NET, JavaScript, JQuery etc.
The issue I'm having is that compared to a traditional desktop application building a rich web based app is more time consuming. This is understandable in terms of the hoops that need to be jumped through for web development. This is a cause of frustration for those not familiar with the ways of the web.
However because people are used to the non web world where I work I need to utilise every possible tool and technique to be productive as possible while building web based applications.
As such I'm looking for what other people do to be as productive as possible while making web based applications. I'm primarily thinking of ASP.NET (not using MVC) but apart from that everything is open.
The best tools for web development, in my opinion, are:
.Net Reflector
Firebug
IE Developer Toolbar
IE Tester and MyDebugBar
Fiddler
You should also look into NHibernate as an option.
The best choice of tools tends to vary quite a bit from one developer to another. It's also very dependent on the details of the type of application you're building.
For me, Visual Studio Team Suite is indispensable. It has a rich set of visual designers and other features that have a big impact on my productivity. Deep integration with bug reporting and source control is another huge time saver (I use Team Foundation Server).
With web forms, you can of course often use drag-and-drop components, which improves productivity for some people (although not me). I can't say I'm a fan of most third-party components. They can be quirky, take a long time to learn well, and then still not do exactly what I want them to. It's also a skill that often isn't portable from one job to the next.
You can leverage jQuery to help simplify scripting -- although even with jQuery I find scripting to be one of the most time-consuming and error prone aspects of web development.
If it's suitable for your environment, you might explore Silverlight. That way, you can often have the best of both worlds, building desktop-like apps using desktop-like tools, but with web-based deployment (Expression Blend is an awesome tool). You can also use Silverlight as a replacement for JavaScript in many cases, with code that's compiled and type-safe.
Good tools on the data side are critical, such as SQL Server Profiler. Visual Studio Team Data (part of Team Suite) is invaluable for it's data generation, unit testing and deployment and management aspects.
Something very underrated by many web developers is building up an appropriate infrastructure: things like logging and performance counters, that can help you track down problems quickly when they occur. A solid configuration system is also important.
In case it helps, I put together a longer list of tools. I also write about something I call the "ultra-fast approach" in my book, which is about more than just building web sites that run fast; it's also about how to build them quickly and reliably: Ultra-Fast ASP.NET.
You should use third party tools.
Telerik RAD Controls and the AJAXToolkit are two such tools available to you. They make much of the 'fancy' stuff built in.
Then, and probably preferably, use JQuery.
With those three options, you can make a fancy web application in the quickest way possible.
Finally be sure your UI and business logic is properly segregated so you can reuse your business logic easier.
There are several ways to increase productivity while building web applications, and they're not too different from desktop programming.
Code re-use. As a shop that is primarily desktop-based, this may not be an immediate option. But as you build your code-base, you'll find that you can use some of the code over for new applications, and even begin building your own customized frameworks.
Development tool knowledge. If a lot of the tools are similar, then you may see immediate benefit from this. If not, it may take more time as the team gets used to new IDEs, etc.
Third-party tools. UI toolkits, backend frameworks. These exist in both worlds, and could be utilized to help jump start development, until items 1 and 2 can be worked in.
A few must-have tools on the client side (i.e. the browser)
FireBug - let's you debug your javascript, DOM, headers, etc
WebDeveloper - provides all sorts of information about the rendering of the page
Selenium - Web UI functional testing framework + tool
(all are firefox add-ons)
Here's some of the tools I use for IE and FireFox, http://www.learn-ajax.com/blog/2008/04/debugging-tools-for-web-applications_03.aspx . Chrome, Opera and Safari also have their own built in client-side web development tools as well.
Most important tools for ANY productive development
Dual large screen monitors
keyboard and mouse that works for YOU.
Comfortable high-backed chair that will save you taking 2 weeks off for physiotherapy down the road.
We're in the initial stages of a large project, and have decided that some form of automated UI testing is likely going to be useful for us, but have not yet sorted out exactly how this is going to work...
The primary goal is to automate a basic install and run-through of the app, so if a developer causes a major breakage (eg: app won't install, network won't connect, window won't display, etc) the testers don't have to waste their time (and get annoyed by) installing and configuring a broken build
A secondary goal is to help testers when dealing with repetitive tasks.
My question is: Who should create these kinds of tests? The implicit assumption in our team has been that the testers will do it, but everything I've read on the net always seems to imply that the developers will create them, as a kind of 'extended unit test'.
Some thoughts:
The developers seem to be in a much better position to do this, given that they know control ID's, classes, etc, and have a much better picture of how the app is working
The testers have the advantage of NOT knowing how the app is working, and hence can produce tests which may be much more useful
I've written some initial scripts using IronRuby and White. This has worked really well, and is powerful enough to do literally anything, but then you need to be able to write code to write the UI tests
All of the automated UI test tools we've tried (TestComplete, etc) seem to be incredibly complex and fragile, and while the testers can use them, it takes them about 100 times longer and they're constantly running into "accidental complexity" caused by the UI test tools.
Our testers can't code, and while they're plenty smart, all I got were funny looks when I suggested that testers could potentially write simple ruby scripts (even though said scripts are about 100x easier to read and write than the mangled mess of buttons and datagrids that seems to be the standard for automated UI test tools).
I'd really appreciate any feedback from others who have tried UI automation in a team of both developers and testers. Who did what, and did it work well? Thanks in advance!
Edit: The application in question is a C# WPF "rich client" application which connects to a server using WCF
Ideally it should really be QA who end up writing the tests. The problem with using a programmatic solution is the learning curve involved in getting the QA people up to speed with using the tool. Developers can certainly help with this learning curve and help the process by mentoring, but it still takes time and is a drag on development.
The alternative is to use a simple GUI tool which backs a language (and data scripts) and enables QA to build scripts visually, delving into the finer details of the language only when really necessary - development can also get involved here also.
The most successful attempts I've seen have definitely been with the latter, but setting this up is the hard part. Selenium has worked well for simple web applications and simple threads through the application. JMeter also (for scripted web conversations for web services) has worked well... Another option which is that of in house built test harness - a simple tool over the top of a scripting language (Groovy, Python, Ruby) that allows QA to put test data into the application either via a GUI or via data files. The data files can be simple properties files, or in more complex cases structured (something like YAML or even Excel) data files. That way they can build the basic smoke tests to start, and later expand that into various scenario driven tests.
Finally... I think rich client apps are way more difficult to test in this way, but it depends on the nature of the language and the tools available to you...
In my experience, testers who can code will switch jobs for a pay raise as developers.
I agree with you on the automated UI testing tools. Every place I've worked that was rich enough to afford WinRunner or LoadRunner couldn't afford the staff to actually use it. The prices may have changed, but back then, these were in the high 5-digit to low 6-digit price tags (think of the price of a starter home). The products were hard to use, and were usually kept uninstalled in a locked cabinet because everyone was afraid of getting in trouble for breaking them.
I worked over 7 years as an application developer before I finally switched to testing and test automation. Testing is much more challenging than coding, and any automation developer who wants to succeed should master testing skills.
Some time ago I put my thoughts on skill matrices in a couple of blog posts.
If interested to discuss:
http://automation-beyond.com/2009/05/28/qa-automation-skill-matrices/
Thanks.
I think having the developers write the tests will be of the most use. That way, you can get "breakage checking" throughout your dev cycle, not just at the end. If you do nightly automated builds, you can catch and fix bugs when they're small, before they grow into huge, mean, man-eating bugs.
What about the testers proposing the tests, and the developers actually writing it ?
I believe at first it largely depends on the tools you use.
Our company currently uses Selenium (We're a Java shop).
The Selenium IDE (which records actions in Firefox) works OK, but developers need to manually correct mistakes it makes against our webapps, so it's not really appropriate for QA to write tests with.
One thing I tried in the past (with some success), was to write library functions as wrappers for Selenium functions. They read as plain english:
selenium.clickButton("Button Text")
...but behind the scenes check for proper layout and tags on the button, has an id etc.
Unfortunately this required a lot of set up to allow easy writing of tests.
I recently became aware of a tool called Twist (from Thoughtworks, built on the Eclipse engine), which is a wrapper for Selenium, allowing plain English style tests to be written. I am hoping to be able to supply this to the testers, who can write simple assertions in plain English!
It automatically creates stubs for new assertions too, so the testers could write the tests, and pass them to developers if they need new code.
I've found the most reasonable option is to have enough specs such that the QA folks can stub out the test, basically figure out what they want to test at each 'screen' or on each component, and stub those out. The stubs should be named such that they're very descriptive as to what they're testing. This also offers a way to crystalize functional requirements. In fact, doing the requirements in this fashion are particularly easy, and help non-technical people really work through the muddy waters of their own though process.
The stubs can be filled in via a combination of QA/dev people. This allows you to CHEAPLY train QA people as to how to write tests, and they typically slurp it up as it furthers their job security.
I think it depends mostly on the skill level of your test team, the tools available, and the team culture with respect to how developers and testers interact with each other. My current situation is that we have a relatively technical test team. All testers are expected to have development skills. In our case, testers write UI Automation. If your test team doesn't have those skills they will not be set up for success. In that case, it may be best for developers to write you UI automation.
Other factors to consider:
What other testing tasks are on the testers' plate?
Who are your customers and what are their expectations related to quality?
What is the skill level of the development team and what is their willingness to take on test automation work?
-Ron
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I have been developing in asp.net since its existence (also classic asp before that) and also I have been using SQL server as my back-end database.
After serious consideration, I now want to change the language I use. Considering the OOP capabilities of the .NET platform, what other languages do you suggest that I start learning instead of ASP.NET and why?
Also what should I use as a database? I have no experience in databases other than the SQL Server.
Django would get my vote.
Like you, I'd been using ASPNET since its creation and then a job forced me to use PHP. Then another. And another. I got to the point where 90% of my time was spent doing PHP and I didn't want to split my time between two completely different work-flows so I just went with it.
PHP, as you may or may not be aware, is a complete scrotum of a language when compared against the relative beauty of languages like C# or even VB.NET. And it's not getting better any way soon. Development frameworks mean you have to upload half-a-million files for each project and it all just feels unneccessary.
So about two months ago I started to look into alternatives. I use Linux now so I bump into Python quite a lot of the time. It looks pretty enough. It's always pretty well formatted (by design) and it has fairly excellent OOP techniques and opportunities.
Then I learnt about the Django ORM so I thought I'd make a quick site with some basic interactive features. I made a secret santa website for my girlfriend's family. Multiple forms, authentication, listing and detail pages and a splash of AJAX. Took me (a complete uber-novice) two days to get functional and the rest of the week to beautify (I'm a slow designer).
Other benefits include its superb built-in caching, a community that really knows how to program stuff, pre-made, reusable apps that you can just plug into your site and go, and python's easy_install and pip that make getting modules so simple. Oh and unlike ASPNET, it'll run on any OS which can make for considerable savings for personal projects.
I've since ported the rest of my PHP sites (and those that I have to maintain) to it and I'm about to start porting over my ASPNET projects. I'm happy.
Databases are pretty much a non-issue in Django. You pick one that's right for the size of your project, plug it in and the ORM handles all the DBIO.
I use SQLite for small-to-medium projects and a MySQL cluster for large projects.
I would use PostgresSQL for your database. It is by far the most feature complete of the open source databases. Though MySQL seems to be regarded as the best for speed. If cost is no object then oracle is obviously a big player.
In terms of language Java is going to be your best bet for similarity to the .Net languages. It is strictly typed and OO like C#. And is widely used in large enterprises, much like .NET.
Of course if you are changing just for the sake of change then maybe its better to switch to something more different. Ruby and Python are the big dynamic languages these days and will offer a different perspective.
Ruby on Rails seems to be very nice choice. Only it is a bit too different and bit too weird. But seems to be most effective, too. RoR is database agnostic, so the choice of database is not about syntax. You don't need to think about which database you use when writing application. You just use RoRs methods to access database and it will automatically wire it to the DB engine.
Or go with PHP and MySQL, it is proven and widely spread. I myself was using MS SQL Server first and switched to MySQL without problems. PHP is a bit dirty language, but it is comfortable to use and well supported and documented, too. If you decide to go this way, try ZEND framework, it solves lots of things and makes writing web applications much easier.
Use Mono, it runs on Linux, Mac and Windows. It runs my ASP.NET program faster in Ubuntu than when it is running on my development machine(Windows XP's IIS, though I haven't yet compared the speed when running on Windows server)
Languages supported on Mono: C#, Java, Boo, Nemerle, VB.NET, PythonNet, IronPython, Oberon, PHP, Object Pascal, Cobra, Component Pascal, Delta Forth, DotLisp, #Smalltalk
For database, use PostgreSQL, it is dubbed as the Oracle of the opensource database. It has many features suitable for enterprise-type system.
http://www.mono-project.com/Main_Page
Why not take a look at ASP.Net MVC, you will capitalize on much of what you already know and is quite a bit different in its approach to websites. Just switching without a compelling reason or target in mind is probably not that useful, however it doesn't hurt to learn another language.
This site is built on ASP.Net MVC and Linq to SQL.
What is the reason for you leaving the .net scene?
A change of language may not fix the root cause.
I switched from LAMP to .net myself due to my job and then gradually in my hobby time to allow me to focus 100% on 1 language.
I switched from LAMP to .net myself due to my job and then gradually in my hobby time to allow me to focus 100% on 1 language.
You probably learned a few things from LAMP that you could apply to .NET. That's the best reason to explore other languages and frameworks.
Dynamic scripting languages can save considerable development time: no compilation, weak typing, and flexibility.
Personally, I love the flexibility of php. There are no abstract, inflexible, complex web controls to learn. I have complete control of my widgets because I can change the underlying code.
I didn't know php is still like a scrabbled scripting language... I don't want to go back to the old times...
No I need the shift to be as smooth as possible. From what I read, it seems ruby is going to be the choise... although Django seems interesting.
To be perfectly honest, the more I discover and experience in JavaScript / jQuery and DOM the less I use asp.net controls and related garbage on my pages. I have reached to a point where I know use ASP.NET for my project's back-end (objects and data classes to send and retrieve data) and standard HTML forms and controls on the front side, using jQuery for DOM manipulation and communication (thorugh ajax) with the server.
Having come to this point in my development career, I thought it would be a good idea to learn a new language that is faster than asp.net, that is not dependent on windows, and that is easier to learn.
I can then buy a macbook and relax :)
SQL Server Express has worked fine for me. I've used a lot of different databases with c#, but only mysql and binary files in production.
ASP.NET isn't a language. It's a framework upon which you can build web sites and web applications.
the reason is not job-centric.
Recently I realised I had enough of
bits-of-pieces that keeps me stuck
with microsoft. e.g. I want to buy a
MacBook but I can't since I need IIS
and VS etc.. (I know I can use windows
on a mac but what's the point)
Are you tired of Microsoft in general or ASP.NET specifically? Or is there a Cult you want to join that requires MacBook ownership? Or are you interested in LAMP or Java development? Do you still want to do web applications or are you more interested in desktop or mobile applications?
As far as databases are concerned, the most obvious alternative would be MySQL. Other options would be PostgreSQL or SQL Lite
I am creating a project called MPDA. It is a simple Dll and application that creates files that act as databases. It is aimed at .NET developers that want to use a database that does NOT impact on system performance on the system it is hosted on. Has no webside dependencies. If you have FTP access you can host it. No install required client or webside. Works on ANY platform with a file hosting ability. On drawback is it is accessible from .NET only.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm going to start coding some automated tests of our presentation soon. It seems that everyone recommends WatiN and Selenium. Which do you prefer for automated testing of ASP.NET web forms? Which of these products work better for you?
As a side note, I noticed that WatiN 2.0 has been in CTP since March 2008, is that something to be concerned about?
I'm currently working hard on a beta release of WatiN 2.0 somewhere in Q1 of 2009. It will be a major upgrade to the current CTP 2.0 versions and will basically give you the same functionality to automate FireFox and IE as version 1.3.0 offers for automating IE.
So no concerns there.
Jeroen van Menen
Lead dev WatiN
If you're looking to make a serious long-term investment in a framework that will continue to be improved and supported by the community, Selenium is probably your best bet. For example, I just came across this info on Matt Raible's blog:
As of Friday, Google has over 50 teams
running over 51K tests per day on
internal Selenium Farm. 96% of these
tests are handled by Selenium RC and
the Farm machines correctly. The other
4% are partly due to RC bugs, partly
to test errors, but isolating the
cause can be difficult. Selenium has
been adopted as the primary technology
for functional testing of web
applications within Google. That's the
good news.
I also went to one of the Selenium meetups recently and learned that Google is putting serious resources into improving Selenium and integrating it with WebDriver, which is an automated testing tool developed by Simon Stewart. One of the major advantages of WebDriver is that it controls the browser itself rather than running inside the browser as a Javascript application, which means that major stumbling blocks like the "same origin" problem will no longer be an issue.
We've tested both and decided to go with WaTiN. As others have pointed out, Selenium does have some nice features not found in WaTiN, but we ran into issues getting Selenium working and once we did it was definitely slower when running tests than WaTiN. If I remember correctly, the setup issues we ran into stemmed from the fact that Selenium had a separate app to control the actual browser where WaTiN did everything in process.
I've been trying 'em both out and here are my initial thoughts...
WatiN
The Good
Fast execution.
Script creation tools are independent projects; there are 2 that I know of: Wax (Excel based, hosted on CodePlex) and WatiN Test Record (hosted on SourceForge). Neither is as robust as Selenium IDE.
Very good IE support. Can attach and detach to/from running instances. Can access native window handles etc. (See script example below).
NuGet packaged, easy to get running in .NET, Visual Studio style environments and keep updated.
The Bad
Googling WatiN (watin xyz) often causes Google to recommend "watir xyz" instead. Not that much documentation out there.
What little there is (documentation), it is confusing; for example: at first blush it would appear that there is no native support for CSS selectors. Especially since there are extensions libraries like 'WatiNCssSelectorExtensions' and many blog articles about alternative techniques (such as injecting jQuery/sizzle into the page). On Stack Overflow, I found a comment by Jeroen van Menen which suggests that there is native support. At least the lead-developer spends time on Stack Overflow :)
No native XPath support.
No out-of-the-box remote execution/grid based execution.
Script Example (C#). You can't do this with Selenium (not that I know off, at least):
class IEManager
{
IE _ie = null;
object _lock = new object();
IE GetInstance(string UrlFragment)
{
lock (_lock)
{
if (_ie == null)
{
var instances = new IECollection(true); //Find all existing IE instances
var match = instances.FirstOrDefault(ie=>ie.Url.Contains(UrlFragment));
_ie = match ?? new IE();
if (match==null) //we created a new instance, so we should clean it up when done!
_ie.AutoClose = true;
}
}
return _ie;
}
}
Selenium
Slower than WatiN (especially since a new process has to be created).
Built-in CSS selectors/XPath support.
Selenium IDE is good (can't say great, but it’s the best in class!).
Feels more Java-ish than .NET-ish...but really, it's programming language agnostic; all commands are sent to an out-of-process 'Driver'. The driver is really a 'host' process for the browser instance. All communication must be serialised in/out across process boundaries, which might explain the speed issues relative to WatiN.
Decoupled processes - "Driver" and "Control" mean more robustness, more complexity, etc., but also easier to create grids/distributed test environments. Would have really liked it if the "distribution" mechanism (i.e. the communication between Driver & Control) were across WebSphere or other existing, robust, message queue manager.
Support chrome and other browsers out of the box.
Despite everything, I went with WatiN in the end; I mainly intend to write small screen-scraping applications and want to use LINQPad for development. Attaching to a remote IE instance (one that I did not spawn myself) is a big plus. I can fiddle around in an existing instance...then run a bit of script...then fiddle again etc. This is harder to do with Selenium, though I suppose "pauses" could be embedded in the script during which time I could fiddle directly with the browser.
The biggest difference is that Selenium has support for different browsers (not just IE or FF, see http://seleniumhq.org/about/platforms.html#browsers.
Also, Selenium has a remote control server (http://seleniumhq.org/projects/remote-control/), which means that you don't need to run the browser on the same machine the test code is running. You can therefore test your Web app. on different OS platforms.
In general I would recommend using Selenium. I've used WatiN few years ago, but I wasn't satisfied with its stability (it has probably improved by now). The biggest plus for Selenium for me is the fact that you can test the Web app. on different browsers.
Neither. Use Coypu. It wraps Selenium. Much more durable. https://github.com/featurist/coypu
Update
Ye Oliver you're right. Ok why's it better?
Personally I've found the Selenium driver for IE in particular to be very fragile - there's a number of 'standard' driver exceptions that I've time again found when driving Selenium for Unit Tests on ajax heavy websites.
Did I mention I want to write my scripts in c# as a Test Project ? Yes Acceptance Tests within a continous build deployment.
Well Coypu deals with the above. It's a wrapper for Selenium that allows test fixtures such as,
browser.Visit("file:///C:/users/adiel/localstuff.htm")
browser.Select("toyota").From("make");
browser.ClickButton("Search");
... which will spin up a (configurable brand of) browser and run the script. It works great with scoped regions and is VERY extendable.
There's more examples at GitHub and as Olvier below mentions, Adrian's video is excellent. I think it's the best way to drive browser based tests in the .Net world and tries to follow it's Ruby namesake capybara
I've used both, they both seem to work ok. My nod is for Selenium as it seemed to have better Ajax support. I believe WaTiN has matured though since last I used it so it should have the same thing.
The biggest thing would be which development environment do you like to be in? Selenium and Watin have recorders but Selenium is in the browser and watin is in visual studio. + and -'s to both of those.
Until now we are a pure Microsoft Shop for delivering solutions for the enterprise and went with WatiN. This may change in the future.
As a more recent source:
Microsoft printed in MSDN Magazine 12/2010 a BDD-Primer with the combination of SpecFlow with WatiN (cool BDD-Behavior Driven Development). Its author Brandon Satrom (msft Developer Evangelist) has also posted in December 2010 a Video Webcast teaching in detail 1:1 his above findings.
There is a Whitepaper from 04/2011 on Supporting ATDD/BDD with SpecLog, SpecFlow and Team Foundation Server (Acceptance Test Driven Development/Behavior Driven Development) from Christian Hassa, whose team built SpecFlow.
I use Watin, but haven't used Selenium. I can say I got up and running quickly on Watin and have had few to no problems. I can't think of anything I have wanted to do that I couldn't figure out with it. HTH
I generally use Selenium, mainly because I like the Selenium IDE plugin for FireFox for recording starting points for my tests.
I recommend WebAii since that's what I've had any success with and when using it my gripes were few. I never tried Selenium and I don't remember using WaTiN much, at least not to the point where I could get it to succesfully work. I don't know of any framework that deals with Windows dialogs gracefully, although WebAii has an interface for implementing your own dialog handlers.
I considered using both. I used the recorder for Selenium to build some tests in FF. I tried to do the same in Watin and found that the Watin Recorder (2.0.9.1228) is completely worthless for our sites. It appeared to be rendering the site in IE6 -- making our site effectively unusable for recording. We don't support IE6. I couldn't find any way to change the browser it is using. I only found one Watin Recorder out there. If there's more than one, or one that is kept up to date, please comment.
The Selenium Recorder IDE for Firefox is simple to use and ports tests to C#. It isn't great at this. I couldn't get porting test suites to work, despite reading a blog post or two that had workarounds. So there's a bit of manipulation of the generated code. Still, it works 90% and that's better than the alternative.
For my money/time, Selenium is superior just for the ease of building new tests. IE doesn't have any good developer toolbars that are anywhere near as good as Firebug, so I'm doing my development in Firefox to begin with, so having a good working recorder in Firefox is a huge bonus.
My conclusion here was a lot like that democracy quote by Churchill: Selenium is the worst form of automated UI testing. Except for all the other ones.
At the risk of going off on a tangent, I'd recommend Axe/WatiN. Axe allows tests to be written in Excel by 'Manual' Testers with no knowledge of the underlying test 'language'. It does need a 'Technician' to write the bespoke actions (IE. Today I had to do a slightly complex Table lookup & cross-reference) but once written the actions can be used in tests by the non-techy testers.
I also heard that the UK Government Gateway project (which I believe has 6K+ tests automated tests) recently ported all their tests from Axe/Winrunner to Axe/Watin within a week!! And many of the tests are pretty complex - I know as I worked on it a few years ago...
I'm looking at Selenium at the moment, as a potential Client uses it. But i do suggest a wee look at Axe as a layer above the 'work horse' tool.
If you have to access iframes, modal dialogs and cross domain iframes WatiN is a way to go. Selenium couldn't handle the iframes it was throwing commandtimeout exceptions. WatiN you could do lot more things especially if the website uses IE specific stuff like ShowModalDialog etc.. WatiN handles all of them very well. I could even do cross domain iframe access.
You will have to do both if you need to do IE and FF testing, but they are only going to work so well for presentation testing. They cant detect if one element is slightly off, just that the elements are present. I dont know of anything that can replace the human eye for UI / presentation testing, though you could do a few things to assist it (take screenshots of the pages at each step for users to review).
What is the best way to test my webforms applications?
Looks like people are loving Watin, and selenium.
Just wondering, why would you call WatiN a unit testing tool? Last time I checked, it ran integration tests.
The best way would be to move all code that doesn't depend on HttpContext to a separate assembly and run unit tests as usual. The rest can be tested with Ivonna. She doesn't test the client behavior, that's where WatiN can be helpful; however, if you want to test your pages or controls in isolation, she's your only choice.
UPDATE: Given WatiN has been stagnant for over a year now, I would direct anyone that needs web ui tests towards selenium, it is in continuous use & development by many contributors, and is actively used by Google.
WatiN is the best that I've found. It integrates into Visual Studio unit testing or nunit & you can do pretty much anything you need in the browser (click links, submit forms, look for text/images, etc.)
See the following questions for similar answers:
What is the best way to do unit testing for ASP web pages (C#)?
Web Application Testing for .Net (watin Test Recorder)
How do you programmatically fill in a form and ‘POST’ a web page?
That's the biggest shortcoming of Webforms -- it's, for all practical reasons, untestable in terms of unit testing of testing controllers, etc.
That is one of the major advantages of the MVC framework.
I tend to favor the approach of separating the buisness logic out of the UI code.
Here's an article that describes a unit test friendly pattern (Model-View-Presenter)
http://www.unit-testing.net/CurrentArticle/How-To-Use-Model-View-Presenter-With-AspNet-WebForms.html
I would use a tool like WaitIn:
" WatiN is Web Application Testing in .NET, and this Test Recorder will generate chunks of source for you by recording your clicks in an embedded IE browser" (from Scott Hanselman's blog - which I found thanks to another post on StackOverflow
WaitIn website
I'd go with WATIR (Web Application Testing in Ruby) - http://wtr.rubyforge.org/. We (Acsys Interactive) have been using for about a year and the tool is great.
I developed a simple wrapper in .NET so that I can execute my WATIR scripts from Unit tests. The framework is incredible and you have entire Ruby power behind you. There's support for Firefox & Safari (FireWatir project).
It's very similar to WATIN (in fact I think WATIN was inspired by WATIR) but I find that WATIR community is much larger than WATIN one.
There're test recorders out there that you can use and tons of tutorials.
It's really your choice. If you feel like the tests need to be in .NET and you don't want to support any other language then your choice is WATIN. On the other hand, if you want to try a fun and quite powerful scripting language (that's what Ruby is) then go for WATIR.
Question to WATIN guys, does it support FireFox/Safari?
Here is a review of Watin,Watir and Selenium
http://adamesterline.com/2007/04/23/watin-watir-and-selenium-reviewed/
Apparently Selenium worked quite slow for the tester but if you'll notice, as one of the comments points out, that this is only the case due to its support of multiple browsers.
However there is a CTP (Community Technology Preview) release of WatiN which offers support for both Internet Explorer and FireFox automation.
I have had a great experience using Selenium. Web tests can be very fragile, but here is an article from my blog where I talk about how to make the tests less fragile.
http://www.unit-testing.net/CurrentArticle/How-To-Make-Web-Tests-Less-Fragile.html