I am currently working on implementing UI tests of .NET web application using Selenium RC.
The tests are now coming together and I am beginning to look at how these will be incorporated into TFS. Our team has only just began using TFS and it would be of great benefit to get these tests running as part of the build on TFS.
If anyone has any experience of this, any knowledge shared would be extremely useful such as best practices to use.
Just to add to Bruce's comments, if you are using VS2010 the "interactive" issues have been resolved in 2010 through the test agent/controller. As long as you have the right attributes on the tests and add the link to the automated test through MTM. The tests can be kicked off as part of the build or through the test controller/agent as a test plan and will automatically update it back into TFS with results and snapshots.
Whether the underlying technology is WatiN or Selenium, it doesn't matter, as long as it is put into a CodedUI test case with the appropriate attributes. Just create the test case cancelling out of the wizard and you'll be able to leverage off the features that TFS has for CodedUI but using the technology of your choice!
Obviously this depends heavily on having access to MTM/agents/controllers as part of TFS but if you don't have it, the hybrid approach works very well.
I haven't used selenium RC with TFS but I have used WatiN a lot so I can share my experiences with that, and no Microsoft Test Manager.
Firstly, what is your goal with Selenium RC is it to scale out your execution, or just use C# as your environment?
Firstly I would look into Selenium 2, as opposed to Selenium RC to see if that fits your needs. For the most part, Selenium 2 will supersede Selenium RC and it has a much cleaner architecture.
I personally write my tests as VS2010 unit tests, and then use the unit testing infrastructure to execute my tests.
I have the "quick and dirty" method of checking out the tests and building them on all my test machines and then manually running them in the unit testing tools with a test list, then uploading the results back to the server.
Another way is to use the VS2010 test agents to push out the tests remotely and execute them that way, but it requires controllers and agents to be configured and running.
One of the big challenges with running tests as part of the build is the need to have an "interactive" session for the tests to run. Personally, I just run developer unit tests as part of the build, and then manually kick of the tests after I have run a build verification test using humans.
I find this hybrid approach works really well.
A couple of tips/best practices I can think of:
It's probably a good idea to make your tests run as fast as possible. When you develop more and more tests the testrun quickly starts to take very long, this results in long builds which is ofcourse a bad thing. Therefore you should think about developing your tests in such a way that they can be run in parallel. This can potentially have huge implications for how you will keep your tests from interferring with eachother for example. It's probably a good idea to think about this but you can ofcourse also start out running tests in serial and then refactoring later on when the long builds start to get annoying...
I think VS2010 unit tests support parallel tests but i'm not sure, personally I use gallio because it supports parallel tests and has a really nice testreport in which you can attach screenshots etc. to a testcase result.
Another best practice is to use pageobject in order to create maintainable tests. You can have a look at this youtube video to get an idea. By the way more valuable selenium vids can be found here
Think about setting up grid 2.0 in your company with a couple of nodes which can be used both by the buildmachine and by developer/tester workstations. Just create a couple of virtual machines which serve as node. That will help you run tests quickly from both developer/tester machines and the buildserver. Make it configurable to run tests locally or on the grid. Sometimes you want browsers to popup on your own machine and sometimes not.
I would also suggest to use alot of logging (for example take lots of screenshots during a testcase), gallio helps you to put these together in a nice report but you can also think about storing testdata in a database. That helps to quickly see what went wrong in failing tests. You really should just try to incorparate this in your testframework which you should be developing along the way.
I dont have much recent experience with TFS2010 but running the tests as part of the build is probably the easy part. It's just a matter of tweaking the builddefinition to call a msbuildtarget or something along those lines.
This is an old thread, but now you can use Protractor, which is a C# port of original one
Install-Package Protractor
and it has a dependency on Selenium.WebDriver
Install-Package Selenium.WebDriver
