How to test for dialog boxes using watin

Note need to add a using for (?) watin.core.dialoghandlers

[Test]
public void Default_PressEnterWithoutSearchTerm_NoDialogDisplayed()
{
using (var browser = new IE())
{
var dialogHandler = new AlertAndConfirmDialogHandler();
browser.DialogWatcher.Add(dialogHandler);

browser.GoTo(_url);
browser.WaitForComplete();

browser.Button(Find.ById(homeSubmitID)).Click();
Assert.AreEqual(0, dialogHandler.Count);
browser.WaitForComplete();
}
}

This asserts for no dialog box (a bad negative test) but could be changed to assert >1 dialogs or even on the dialog message.

Notes From OpenSource .Net Exchange III

Really enjoyed the meeting - there was a good buzz about it. Nice venue and the beer and pizzas were a good touch. Something to consider for AgileYorkshire. Gojko has posted a good overview here so I wont repeat that but other things which I made a note of were:

• Check out the universal test runner Gallio which was mentioned during the presentation on Concordion. This would be useful if we started to run several types of tests (Unit, Integration, Acceptance, etc) during CI or just developers.
• Check out the new tools from MS - "Web Platform Installer" and "Web Deployment Tool". Seems like it might be a useful as a way of getting a replica of the live environment. One comment was that it has a steep learning curve but was very powerful once mastered. There are several OSS applications (e.g. wikis) available in an "application store" which might be useful. Also seems to be the way you should get and install ASP.MVC
• I was also interested enough in OpenRasta to want to do a bit more digging. It seemed really powerful and that it might be possible to start using it in an existing ASP.NET app so that it is inherently more testable and with no requirement to restructure folders etc.
• During the presentation on MPI found myself wondering if this is a way of making the processing of vehicle geolocation data (velocity, events, distance etc) in a more scalable way but suspect that this would be using a sledgehammer to crack a nut - there are probably better ways based on message queues and services. Interested that it will run on Mono which opens up cheap linux servers to be used for processing but in an MS environment.
• Spoke to Wendy from SkillsMatter about potential collaberation with regard to sponsorship, speakers and technical help. I need to get in touch with them with some concrete proposals.
• [Added later] Had a conversation in the pub afterwards with a guy who had raised the question in the meeting about the view engines regarding what the reaction of designers was when given a view to develop. I'd always assumed that you could give a designer a view and a collection of view data and they would be happy to use this data (with iterations, conditionals and other programming structures). Turns out this may be very far from the case and many designers would baulk at this. He felt that it was better to get the designers to mock something up and for the developers to add the view data later preferably as a paired task with a designer. There does seem to be an impedance mismatch between the designer and developer parts of generating a view which I had not appreciated.
  

Written on the train on my way home (posted the following day). Notes on the BBC visit to follow.

Visit to moveme.com

Just back from an interesting morning with the development team at moveme. Paired with James, their lead developer, and over the morning discussed their approach to agile mixed in with the TTD coding. First thing I noticed was that the tool set was different. They use Tortoise and subversion (no surprise there) but they use xUnit coupled with testdriven.net. xUnit is new to me and they felt it encouraged better practices and was more extensible. It was also strange with testdriven.net where you get pass/fail text rather than reds and greens but I could get used to it. They also seemed to be (vehemently) opposed to resharper but I didn't get chance to ask why. James favoured CC.NET over TeamCity as he felt it gave him more control. More food for thought. Might ask them to comment on this.

The interesting stuff was the management buyin of agile (their CEO is a scrum advocate) and the fact that the dev team want to move to more lean/kanban way of working based on there need to respond very rapidly to changing business requirements. These changes come from monitoring the web stats and looking to monitize behaviour. They gave a great example of where they had been able to spot an opportunity to to add a referal link to generate click through money and acted upon it during a sprint after discussing the cost/benefits of doing such a thing. I can see how the whole kanban pull model might work. I'd never been convinced that dev teams needed to respond in days rather than weeks but this example convinced me.

Other things of note are that they felt that they worked better without a tester. That might be because they had had an old school QA tester who found it difficult to work in an agile environment but they didn't think this was the case. Note sure how this approach will scale as the dev team grows again (there was 4 of them). As always in successful teams they had an excellent onsite customer proxy who understood the domain and was vision, rather than sales, focused.

They used the concept of Golden Hours which seemed to be a useful practice and worth trying.

I need to check out https://www.ohloh.net/p/simplewebservices which is a project of Alans as I'm not sure what it gives. Some swotting for the return train trip perhaps.

All in all a worthwhile visit.