Write to TinyMCE in a WatiN integration test

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.

Since the application uses TinyMCE for most of it’s text inputs I had to find a way to write to it within the tests. With Selenium Nick Bartlett had a solution. For WatiN I used the Eval method and executed the setContent JavaScript method in the TinyMCE API.

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.

Start and stop Selenium Server with NUnit

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.

  1. I started by downloading the Selenium RC and unzipped it to C:SeleniumSelenium-RC
  2. I created a .NET project where I referenced the ThoughtWorks DLLs in C:SeleniumSelenium-RCselenium-dotnet-client-driver-1.0.1
  3. I added a new class to where I copied the Selenium getting started C# class
  4. I added my own TestFixtureSetup and a TestFixtureTeardown to this class. TestFixtureSetup launches the Selenium Server and TestFixtureTeardown closes it

Here is the class for starting the Selenium Server and the example Selenium test.

using System;
using System.Diagnostics;
using System.Text;
using NUnit.Framework;
using Selenium;

namespace Test.UI.Web.Selenium
	public class SeleniumGoogleTest
		private ISelenium selenium;
		private StringBuilder verificationErrors;

		private Process seleniumServer;
		private readonly ProcessStartInfo seleniumServerProcessStartInfo = new ProcessStartInfo("java", @"-jar C:SeleniumSelenium-RCselenium-server-1.0.1selenium-server.jar");

		public void TestFixtureSetup() {
			seleniumServer = Process.Start(seleniumServerProcessStartInfo);

		public void TestFixtureTearDown() {

		public void SetupTest()
			selenium = new DefaultSelenium("localhost", 4444, "*iexplore", "http://localhost:4444");
			verificationErrors = new StringBuilder();

		public void TeardownTest()
			} catch (Exception)
				//Ignore errors if unable to close the browser
			Assert.AreEqual("", verificationErrors.ToString());

		public void OpenGoogleWebSite()


Pair programming to close the gap between business and development

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!

Pair programming – Research

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.

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.

The Agile Toolkit Podcast did an interview with Arlo Belshee Tue, 9 August 2005

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.

A Study About Pair Programming in Practice

During a course at Lund University the students answered two surveys about pair programming. The first before the course. The second after.

The students were a bit more negative to pair programming after the course.

Practical recommendations about how to assign partners and tasks. What role should a team coach have in a pair programming team. How often you should change partners.

Most important personality types are not technical skills but social skills and worst personality types are dominant and ineffective.

Weaker developers liked pair programming more than the strongest.

  • Authors: Mia Nyström, Johan Rix, Karin Wanhainen at Lund University
  • 2002
  • Original title: En studie om parprogrammering i praktiken
  • PDF: NystromWanhainenRix.pdf
    Appendix: http://www.cs.lth.se/EDA270/Djupstudier/Articles/2001-2002/NRW-bilagor.pdf

Running WatiN tests in SharpDevelop

I tried to run my WatiN tests in the test runner in SharpDevelop and got stuck on the following error:

System.Threading.ThreadStateException : The CurrentThread needs to have it's ApartmentState set to ApartmentState.STA to be able to automate Internet Explorer.

If you are running your tests with MBUnit you can add the following to your TestFixture:

[TestFixture(ApartmentState = ApartmentState.STA)]

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.

How to dissable Protected Mode in IE
How to disable Protected Mode in IE