Last week I worked on some integration tests in Selenium. Today I’m redoing the same test in WatiN to get a feel for both tools.
var js = "tinyMCE.get('tinyTextAreaId').setContent('some html');";
var s = Document.Eval(js);
This would work just as good with Selenium and it has one advantage over setting the text areas. It executes the eventual cleanup rules in TinyMCE before it sets the text.
I want to have our Selenium tests to run automatically the same way as our other NUnit tests does. This means that I want to have the Selenium Server started automatically before running the test cases.
I started by downloading the Selenium RC and unzipped it to C:SeleniumSelenium-RC
I created a .NET project where I referenced the ThoughtWorks DLLs in C:SeleniumSelenium-RCselenium-dotnet-client-driver-1.0.1
Before I started pairing I often felt that there was a gap between business and development -departments. Communication was mostly done via bug trackers or specifications. Issues were ofter dealt with via e-mail and misconceptions were common.
Since I started pairing I feel a greater (not perfect but better!) contact to the business and I think it’s because I’m used to take discussions. Both about coding details, but also and more important about usefulness of requirements. If we are stuck on an issue we walk over to business and solve the issue instead of making it an e-mail-reply-cc-all-thing.
If I’m working on an issue with a person I don’t know I start out by shaking hands and talking to the person about what he or she does in the company and how they interact with the tools. I tell them what resources we have for the issue and we discuss a possible solution together. Just common sense.
It feels like software development is a too social activity to be done alone! At least for me!
Listen to Deep Fried Bytes – Episode 35, Chariot Tech Cast – Episode 39 and Hanselminutes – Episode 171 for more info about pair programming and other goodness about the software craftsmanship!
I’ve read up on some pair programming research. Here is the different papers I’ve read. With a short description for each.
Strengthening the Case for Pair-Programming
They compare results from professional developers working with and without pair programming and teams at the university doing both pair programming and non pair programming. In all cases pair programming deliver better results.
Authors: Laurie Williams at North Carolina State University, Robert R. Kessler at University of Utah, Ward Cunningham at Cunningham & Cunningham, Inc & Ron Jeffries
Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience
The optimal time between switching partner is 90 minutes and inexperienced developers solve problems both faster and better that people with previous knowledge about the problem. Beginners luck or just that you are more open without a baggage of experience?
A new developer was totally integrated to the team within 3 weeks of work. When not pairing they noticed a huge impact on productive. In 18 months the longest time it took to find and fix a bug was 6 hours. They also found out that a team is most productive when they own, manage and assign all tasks themselves.
Adventures in Promiscuous Pairing: Seeking Beginner’s Mind
They verified the performance boost described in Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience, which means short times (~90 min) between changing pairing partner. They verified the results but it also broke the team.
But I couldn’t find any similar for NUnit. Instead I changed how SharpDevelop launches it’s tests. Click; Tools / Options / Tools / Unit Tests and deselect Run tests on separate thread. Run the tests again.
And I got the following error:
System.InvalidOperationException : Process has exited, so the requested information is not available.
I tried to disable Protected Mode in Internet Explorer and the tests ran fine.