Friday 22 August 2008

WatiN, Ajax and some Extension Methods

Whilst I've been working with WatiN over the past couple of months I have encountered a few issues especially that unfortunately WatiN was unable to solve straight out of the box, so I thought I would knock a post together that contains the extension methods I have managed to cobble together from various sources on the Internet and a little bit from my own head.

WaitUntilEnabled

I encountered this issue whilst working with the CascadingDropDown provided by the Ajax Control Toolkit, now WatiN does provide a function called WaitUntil which allows you to pass in the name of the attribute you want to examine and the value that you expect the attribute to become, unfortunately however, it seems the CascadingDropDown adds a "disabled" attribute with a value of "true" to the html page. The drop down list then becomes enabled when the disabled attribute no longer exists or is set to false. Therefore it was necessary to write an extension method that waited until the control no longer had a "disabled" property with a value of "true. The method is as follows:

        /// <summary>
///
Waits until the specified element is enabled within the web page.
/// </summary>
/// <param name="element">
The element.</param>
public static T WaitUntilEnabled<T>(this IElement element) where T : class
{
var timer = new SimpleTimer(IE.Settings.WaitForCompleteTimeOut);

do
{
var value = element.GetAttributeValue("disabled");

if (value != "True" &&
value != "true")
{
return element as T;
}
Thread.Sleep(200);
}
while (!timer.Elapsed);

throw new TimeoutException("Waited too long for " + element.Id + " to become enabled");
}



UPDATED 15/09/08: Whilst preparing for my Ready, Steady, Speak session at Remix I came across a small bug where the value retrieved for the disabled attribute was "True" instead of "true" as initially thought, I don't know what caused the difference to occur but I have added the additional check anyway.



The usage of this method is as follows:



        ie.SelectList(Find.ById("MyCascadingDropDown")).WaitUntilEnabled().Select("AValue");



IfExists



This is just an extension method I wrote to make it a little easier to work with elements that don't exist:



        /// <summary>
///
Checks whether the element exists, if so performs the specified action,
/// otherwise just returns the current element object.
/// </summary>
/// <typeparam name="T">
The type of element to check for existence.</typeparam>
/// <param name="element">
The element.</param>
/// <param name="action">
The action.</param>
/// <returns></returns>
public static T IfExists<T>(this Element element, Action<T> action) where T : class
{
if (element.Exists)
{
action(element as T);
}

return element as T;
}


This method can be used as follows:



        ie.TextField(Find.ById("MyTextField")).IfExists<TextField>(e => e.TypeText("AValue"));


 


WaitForAsyncPostBackToComplete



If you are working with controls within an update panel you will inevitably come across a situation where a value is changed via an async postback and whilst that postback is taking place WatiN will try and perform another action which results in an error.The solution to this problem was found after searching the Internet for a little while and I came across this post which explains the problem in a little more detail.



I have modified the original method slightly to make it an extension for the IE browser object, it is used to determine whether the current page is within an asynchronous postback, unfortunately in order to use this method the page you are testing needs to have a JavaScript method defined so if you don't have control over the website you could be a little stuck, here is the Javascript:




<script type="text/javascript">      
var
prm = Sys.WebForms.PageRequestManager.getInstance();
function IsPageInAsyncPostback()
{
return prm.get_isInAsyncPostBack();
}
</script>




The C# method implementation is as follows:



        /// <summary>
///
Waits for async post back to complete.
/// </summary>
/// <param name="ie">
The ie instance to use.
</param>
public static void WaitForAsyncPostBackToComplete(this IE ie)
{
bool isInPostback = true;
while (isInPostback)
{
isInPostback = Convert.ToBoolean(ie.Eval("IsPageInAsyncPostback();"));
if (isInPostback)
{
Thread.Sleep(200);
//sleep for 200ms and query again
}
}
}


After a kind comment from Jo (see below), I have modified this as there is no need to place the IsPageInAsyncPostback method inside of the page, I just needed to modify the Eval method to make the entire call, as follows:



        /// <summary>
///
Waits for async post back to complete.
/// </summary>
/// <param name="ie">
The ie instance to use.</param>
public static void WaitForAsyncPostBackToComplete(this IBrowser ie)
{
switch (ie.BrowserType)
{
case BrowserType.InternetExplorer:
{
bool isInPostback = true;
while (isInPostback)
{
isInPostback = Convert.ToBoolean(ie.Eval("Sys.WebForms.PageRequestManager.getInstance().get_isInAsyncPostBack();"));
if (isInPostback)
{
Thread.Sleep(200); //sleep for 200ms and query again
}
}
break;
}
}
}



And can be used like this:



            SelectList list = ie.SelectList(Find.ById("MySelectList"));
list.Option("TestOption").Select();

ie.WaitForAsyncPostBackToComplete();

SelectList childList = ie.SelectList(Find.ById("MyChildSelectList"));
list.Option("TestChildOption").Select();



ByPartialId



The final useful method is ByPartialId, this is merely a wrapper around a regular expression but it does save quite a bit of typing and needing to remember the regular expression syntax. I found this on Ayende Rahien's blog:



        /// <summary>
///
Gets an attribute constraint using a partial id.
/// </summary>
/// <param name="partialElementId">
The partial element id.</param>
/// <returns></returns>
public static AttributeConstraint ByPartialId(string partialElementId)
{
return Find.ById(new Regex(".*" + partialElementId + "$"));
}


 

Foundations Of Programming - eBook Review

I was recently catching up on some articles from the Code Better RSS feed and came across this Foundations of Programming eBook, which is essentially a composition of a number of Karl Seguin's posts on the code better site all neatly presented in an eBook, best of all it's free. I had missed many of Karl's original posts so I decided to download it, take a look and give it a quick review if anyone is interested.

Chapter 1: ALT .NET - this chapter gives quite a nice overview of what ALT .NET is all about, why it exists and where it fits within the community. It also contains some explanations for all of those little acronyms and terms that you hear bouncing around all over place, items such as YAGNI (You Aren't Going to Need It!) and DRY (Don't Repeat Yourself), Coupling, Last Responsible Moment.

Chapter 2: Domain Driven Design - a brief introduction into what DDD is and how it differs from Data-Centric design. Karl uses very simple code samples to get his point across but these do the job well and the tips and tricks section is well worth a read to refresh your knowledge on typical patterns and practices you should be following when developing software applications.

Chapter 3 - Persistence - it seems that the concept of persistence and persistence ignorance is a bit of a buzz word at the moment, what with various discussions about Entity Framework vs NHibernate etc (just Google these terms and you'll come up with some discussion or another). In this chapter Karl neatly summarises the main issue in-hand i.e. the Object-Relational Impedance Mismatch and continues to discuss the use of Data Mappers and, with the use of some example code, highlights the drawbacks of using manual mapping (hand writing the code to perform the mapping of relational to object data), which had I not been convinced of already, this chapter would have pushed me to look for alternatives. I think the title of this chapter is a little misleading as it does mainly focus on manual data mapping and I was expecting the chapter to go into more details about other persistence mechanisms available, I'll keep reading and see where it takes me.

Chapter 4 - Dependency Injection - this section discusses the balance between decoupling and coupling of items within an application, introduces the concept of unit testing which requires at least some form of decoupling and details how the Dependency Injection pattern can be used. The chapter  also focuses on the StructureMap dependency injection tool written by fellow CodeBetter blogger Jeremy Miller, there are plenty of other DI frameworks out there such as Castle Windsor, Unity, ObjectBuilder each has their own pro's and con's so I leave it to you to make a decision on which might be the most preferable for your situation.

Chapter 5 - Unit Testing - the previous chapter briefly introduced unit testing as a way of introducing the need for decoupling within a system, this section delves a little more into unit testing and why should we use it, I especially liked the section on "Why Wasn't I Unit Testing 3 Years Ago?" which rang very true to me. Karl then goes on to discuss unit testing and the tools you need to do it, these include NUnit, TestDriven .NET and RhinoMocks and he details simple some code examples to give the reader and idea of the kind of things you can do with them.

One point worthy of note is that Karl mentions that UI testing "is complicated and suffers from very tight coupling" which is true, but I would definitely recommend looking into integrating WatiN into your continuous integration build process, the tests are not be as fast as unit tests so you may want to use them in a separate build process but I believe that can be equally invaluable to ensure the UI meets the needs of the user.

Also, when it comes to testing of the database, I have recently found some success in using a LINQ to SQL data context which exposes the stored procedures within the database can be extremely useful for testing individual stored procedures and ensuring they perform as expected (may be I'll do a blog about that some day).

Chapter 6 - Object Relational Mappers - starting head on with details about the Stored Procedures vs Inline SQL debate, Karl explains some of the key points involved in this discussion and argues the reasons for inline SQL over stored procs which leads on to the use of an object relational mapping tool. I for one agree with Karl's arguments and believe that the use of an O/R Mapper should be a developers first port of call and then stream line to use stored procs when bottle necks appear. The chapter then moves on and describes how to configure and use NHibernate for your O/R Mappings, recently I have had a lot of experience of LINQ to SQL and I find this to be pretty useful even though it probably lacks a level of abstraction that tools such as NHibernate would provide, it certainly does the job if your just focusing of SQL Server databases in a smallish application.

Chapter 7 - Back to Basics: Memory - I personally believe every developer should read this section even if its just to recap your knowledge on these items, it's always good to keep an idea of what the memory usage of your application in your mind even when in a managed environment. Karl covers all of the areas you would expect to see such as Boxing, ByRef, Managed Memory Leaks, Fragmentation and Pinning and the use of IDisposable. The chapter is relatively brief considering the subject matter but it is easy to read and digest, compared to CLR via C# (I book I would thoroughly recommend you get if you haven't got it already) Karl's is a lot more lightweight but serves the purpose of getting developers thinking about the things that matter.

Chapter 8 - Back to Basics: Exceptions - the suggested exception handling is simply two rules 1) Only handle exceptions that you can actually do something about, and 2) You can't do anything about the vast majority of exceptions and Karl goes on to state that "Most new developers do the exact opposite of the first rule, and fight hopelessly against the second. I believe he is right, exception handling can actually be quite an overwhelming concept and developers can easily be too defensive when dealing with them. Karl continues to highlight what to do when handling exceptions that you can do something with also asserts that exception swallowing is bad. The chapter continues to detail how to throw exceptions and the subtle differences this can have on the stack trace, when to throw exceptions i.e. in exceptional circumstances or when expected behaviour cannot be executed. Finally, the chapter rounds up with a section on custom exceptions.

Chapter 9 - Back to Basics: Proxy This and Proxy That - the chapter looks inheritance and polymorphism in terms of the Proxy Domain Pattern and how this is used within NHibernate to handle lazy loading of objects. There is an interesting side note about NHibernate which is that it is considered to be a frictionless or transparent O/R Mapper because it doesn't require modification of any of your domain classes, although if you require lazy loading then you must mark all of your methods as virtual but you still don't have to add NHibernate specific constructs to your classes. The chapter then turns into a discussion about the lazy loading capabilities of NHibernate and how the proxy pattern is used to achieve this. The intention of the chapter was to make the reader think about what methods should and shouldn't be virtual, I am not sure whether this was achieved but it certainly got me thinking a little bit more about looking into NHibernate.

Chapter 10 - Wrapping It Up - this final chapter simply summarises the contents of the eBook and Karl gives what I consider to be a good list of core principles to good software engineering, I have summarised these as follows (see the eBook for more detail):

  • The most flexible solution is the simplest (YAGNI, DRY, KISS and explicitness)
  • Coupling is unavoidable, but must be minimised
  • You are responsible for the code you write, test your code because this helps you identify bad coupling, find awkwardness in your API, document behaviour and expectations, and lets you make small and radical changes with far greater confidence and far less risk
  • It's more fun developing projects using agile and iterative development
  • Always look for alternatives and learn all of the time

I must say I really enjoyed reading this eBook, so much so that it inspired me to write this review of it. At only 79 pages it is manageable and IMO makes some absolutely valid points about how to "Code Better", reading this eBook will be a great learning aid for those wanting to progress their programming knowledge and a stark reminder for those with a greater knowledge that it is always worth reminding yourself of your coding principles, practices and understanding of the underlying framework that you work with everyday.

The eBook has opened my eyes to the way of the ALT .NETer and I am now far more interested in learning about NHibernate and how it could make my life as a programmer a better place to be. Some might say that the focus on NHibernate should not be considered as a "Foundation of Programming" but the principles that lie behind the development of NHibernate certainly should be. All in all I would definitely recommend reading this eBook when you have a spare  5 minutes.

WatiN Nugget at NxtGen Southampton

So last night I managed to get through my nugget on WatiN relatively unscathed, the demo overran which I was a little disappointed about but I hope everybody took something from it.

I was in a small dilemma prior to performing the nugget as I wanted to talk about how great WatiN is and demonstrate what you can do with it but in the back of my mind I knew that it is very easy for you WatiN tests to become large in number and unmaintainable, so I wanted to talk about the controller framework I have been developing to give people an idea of the kind of things you can do to make sure your tests do not get out of hand.

I shall be performing this nugget again at the Cambridge NxtGenUG, its titled Not Wifeswap, Coordinator Swap, the title doesn't really tell you what its about but basically John and I are going to perform the session we did last night up at the Microsoft Research Centre where the Cambridge boys are based.

So the main lessons learned from last nights session were I think that 15 minutes isn't long enough (by a long way) to talk about best practices of writing WatiN tests, so I shall just focus on what WatiN can do, may be show a few more of the functions for working Ajax based web sites and then just point people to my blog for more information about the framework etc. If anyone reading my blog attended the event last night, I'd be really interested in your feedback.

Wednesday 20 August 2008

WatiN Controller Framework - Part I

A little while back I blogged about setting up and using WatiN and detailed how to create a simple unit test and also use the WatiN Test Recorder to create a simple test run. I also mentioned that I was working on a controller framework to aid in the development of automated web application tests and make it a bit easier to knock up tests for new web applications. This post is the first in a series ( I am not sure how long the series will be yet but I'll let you know when I know) of posts that will explain the framework together with reasons why I have chosen to do things in a particular way.

I originally started working on my controller framework a couple of months ago and I was about a week or two into development when I came across this WATiN/R Testing Design Pattern article, which discusses the importance of separating the logic for controlling the page from the tests themselves ensuring that you have maximum re-usability of your page controlling logic. This was also one of the driving forces behind my framework but rather than using static classes and I wanted a more fluent interface that allowed my domain specific controllers to easily flow from one controller to the next making my tests even easier to read, something like this:

        [TestMethod]
public void ChangeEmployeeDetails()
{
Northwind
.GoToEmployees()
.ViewDetails("Davolio,Nancy")
.ChangeDetails(new EmployeeDetails()
{
FirstName = "Test",
LastName = "Employee",
ReportsTo = "Steven Buchanan"
});
}



The application I was working on was a very large web site that contained a lot of wizard logic and when we were adding new functionality to the wizards we seemed to be spending a great deal of time entering dummy data just to get to the point in the wizard that we really wanted to test. For example, a typical wizard would be (each step containing its own validation logic meaning that specific data must be entered):




  1. Enter Member Details i.e. first name last name, date of birth, contact phone number etc


  2. Enter Address Details


  3. Enter Marketing Information


  4. Enter Package Details


  5. Enter Payment Details


  6. Show Package Summary


  7. Finish the wizard



Frequently throughout development of the application we were required to make modifications to these wizards with new user requirements etc, so in order to modify something on step 5 Enter Payment Details, and for us to test the UI functionality it would be necessary enter all of the details for steps 1 to 4 time and time again which soon became very repetitive, tiresome and boring. Also, our application is multi-lingual so there was a requirement to be able to automate the site using different language and regional settings.



So with this in mind I set about creating a framework of controllers that allowed me to concentrate on adding the functionality for automating parts of the web site without repeating a bunch of unit test code. The base controllers are quite simple, here is a class diagram showing the relationships:



image



As can be seen in the image above, there are three page controllers:




  •  HomePageController<T> - this serves as the main entry point into the web site and should represent the first page that a user would be directed to when they arrive at the web site, there should only ever be one home page controller per web site. The HomePageController<T> is the only controller that maintains an instance of the WatiN.Core.IE object, any call made to the Browser property of the HomePageController<T> will either a) use an existing IE instance, b) search for an existing IE instance that matches a pre-defined base URL or c) create a new instance of IE and navigate to the pre-defined home page.


  • PageController<T> - any other page within the web site should be represented by controller that inherits from the PageController<T> class unless the page contains a wizard in which case the WizardPageController<T> should be used. The PageController<T> base class provides some simple methods that enable easier use of a fluent interface


  • WizardPageController<T> - any page that contains a wizard should inherit from this controller as this base class provides functionality that enables easy manipulation of the wizard on the page from within the unit tests.



As mentioned in my previous post setting up and using WatiN, I shall be using the Northwind ASP .NET Sample web site with Ajax to demonstrate how you would create a simple controller framework, the following image is a snap shot of the Northwind home page:



image



And this image shows some of the controllers I have created for the Northwind web site:



image



As you can see, the NorthwindController inherits from the HomePageController<T> class serving as the entry point into the web site, when the controller is defined a custom attribute is used to define what the base URL for the web site is and also what the name of the home page is:



[Url("http://localhost/Northwind", "Default.aspx")]
public class NorthwindController : HomePageController<NorthwindController> {}



The NorthwindController contains properties that are controllers for other parts of the web site such as the Employees page, Supplier page etc, I have also added a SampleWizard page to the site to demonstrate the use of a wizard page controller. Each property simply returns a new instance of the required controller type on each get request and looks something like this:



public EmployeeController EmployeeController
{
get { return new EmployeeController(this, this); }
}


The NorthwindController also exposes methods with the following name signature PageController<T> GoTo<PageName>(). Each of these methods implement the WatiN logic necessary to navigate to the relevant page within the web site and then returns the page controller that represents that page, this allows the fluent interface to be used from within the unit tests, a typical method might look like this:



        public EmployeeController GoToEmployees()
{
Browser.Link(Find.ByText("Employees")).Click();
return EmployeeController;
}


So the GoTo method simply uses the page controllers Browser instance (WatiN) to find a hyper link with the text value of "Employees" (this could equally look for a hyperlink with an ID) and then clicks the link, after clicking the link the EmployeeController is returned allowing the test writer to immediately take control of the page that is being navigated to. If the link doesn't go to a page that can be controlled by the EmployeeController then the test will fail and the developer will know that something has been changed incorrectly.



The subsequent page controllers also expose GoTo methods when the page they represent contain links to other parts of the web site and they will generally also methods that expose the functionality available on that page. I think the easiest way to demonstrate this is show you an image of the Northwind Employees.aspx page:



image



Looking at this page you can see a couple of functions that would need to be exposed by the EmployeeController, these would include InsertNewEmployee, ViewEmployeeDetails and EditEmployeeDetails, in this example we shall focus on the ViewEmployeeDetails method. So in order to view the details of an employee we need to know what the name of the employee is, so this defines the parameter that will be required on our method and we must also find the "Details" link that is in the table row that contains the name of the employee. The resultant method call looks something like this:



        public EmployeeDetailsController ViewEmployeeDetails(string employeeName)
{
((TableCell) Browser.Span(Find.ByText(employeeName)).Parent).ParentTableRow.Link(Find.ByText("Details")).Click();
return EmployeeDetailsController;
}


The method uses the page controller's Browser (via WatiN) to find a span via it's text value containing the name of the required employee. We then need to get the span's parent (a table cell) and obtain the table cell's parent row, using this row we then look for the hyperlink that contains the text "Details" and click it. After clicking the details link the page will be redirected to the Employee Details page and therefore returns the EmployeeDetailsController which then exposes the functionality available on this page. The Employee Details page looks like this:



image



Therefore, the EmployeeDetailsController exposes a method called ChangeDetails which takes a EmployeeDetails class as a parameter. This class simply serves the purpose of holding all of the information that could be changed for any given employee. The ChangeDetails method looks something like this:



        public EmployeeController ChangeDetails(EmployeeDetails details)
{
Browser.TextField(ByPartialId("txtFirstname")).IfExists<TextField>(tf => tf.TypeText(details.FirstName));
Browser.TextField(ByPartialId("txtLastname")).IfExists<TextField>(tf => tf.TypeText(details.LastName));
Browser.SelectList(ByPartialId("ddReportsTo")).IfExists<SelectList>(tf => tf.Select(details.ReportsTo));
Browser.Button(ByPartialId("btEdit")).Click();
//...further fields removed for brevity
return GoToEmployees();
}


As can be seen, this method takes the EmployeeDetails class, using the page controller's Browser (via WatiN) finds the relevant controls on the page and uses the values contained within the EmployeeDetails class to enter the details. Finally, the save button is clicked and the user is returned to the Employees page. The IfExists<T> method is an extension method that I have added that enables testing whether a WatiN element exists prior to performing a relevant action, this is not part of the WatiN install, I shall cover some of the extension methods and helpers that I have needed in a later post.



Conclusion



In this post I have given you a simple introduction to the WatiN controller framework and how you would use it within your WatiN test development. I shall be creating some more posts about various things, including controlling wizards with the WizardPageController and WatiN Extension Methods and Helpers, I encountered during development of the controller framework so stay tuned.



The source code for this is not currently on CodePlex or SourceForge but if people are interested in learning more and seeing the source code just leave a comment and if there is enough interest I shall post the code to one of these sites or just throw up a zip file. Oh and by the way if anyone can think of a better name for this I would appreciate it, there is currently WatiN, Wax, WatiN Fixture, Watin Controller Framework doesn't quite fit and I think the acronym WCF has already been taken? :-).

Thursday 14 August 2008

Setting up and using WatiN

I am going to be doing a 10 minute nugget about WatiN at NxtGenUG Southampton on Thursday 21st August, so as I was preparing for it, I thought I would put together a little post about the relevant details.

So to get started with WatiN you need some basic tools:

  • WatiN Framework - this can be downloaded from here, at the time of writing the current RTM version is 1.2.1 but version 2.0 is available as a CTP, I shall be focusing on version 1.2.1 for my nugget. Simply download the MSI/zip of your choice, I have chosen the WatiN-1.2.1.4000-net-2.0.msi.
  • WatiN Test Recorder - this is really useful for getting you started with writing WatiN tests, it can be downloaded from here. This is currently at version 1.0.1b and as far as I know there is only a single download.
  • IE Developer Toolbar - WatiN 1.2.1 only supports IE, but 2.0 has support for FireFox. This is an essential tool for any kind of web development let alone for use when developing WatiN tests, it lets you inspect the html elements of a web page by simply pointing and clicking at the element you want to inspect. This can be downloaded from here.

These are the basic tools you will need but to make some real use of WatiN you will want to combine it with your favourite unit test framework, I've chosen MS Test simply because its the test tool of choice at my current place of work but WatiN will work with other tools such as NUnit etc.

Writing Your First WatiN Test

Once you've installed the above tools its time to start writing your first WatiN test, because my demonstration is going to be in a hall with no access to the Internet I need to use a locally hosted web site so I thought I would download a Northwind ASP .NET Sample web site with Ajax, now this is certainly not the prettiest web site or even the most functional but hey, it serves the purpose :-). Once you've downloaded the zip file, simply extract it to a location of your choice and setup an IIS application, remembering to change the connection string in the web.config to point to your version of the Northwind database.

Using VS2008 create a new test project called Northwind.Watin.Tests, delete theimage AuthoringTests.txt and rename the UnitTest1.cs file to something like NorthwindTests.cs.

Next we need to add a reference to our installed WatiN.Core assembly, the installer places the file in C:\Program Files\WatiN\1.2.1-net-2.0\bin folder but you can move it elsewhere if you desire.

We shall create a test method called GoToNorthwind that will simply perform the job of creating a Internet Explorer instance, entering the url of our Northwind application in the address bar and navigating to our Northwind web site. Ensure that you have added the

using WatiN.Core;



at the top of the page and the create a test method that looks something like this:



        [TestMethod]
public void GoToNorthwind()
{
using(var ie = new IE())
{
ie.GoTo("http://localhost/Northwind/default.aspx");
Assert.IsTrue(ie.ContainsText("Northwind"));
}
}



So quite simply this test creates a new instance of IE, which is essentially an automation wrapper around Internet explorer, enters the url specified and in the address bar and then asserts that the IE instance contains the text "Northwind", obviously we could have done a bit more of test here but you get the picture.





Using WatiN Test Recorder to Create a Test



This time we'll use the WatiN Test Recorder to create the same test, launch an instance of the recorder, it should look something like the following, next in the "Test Name" text box type the name of the test "GoToNorthwind" and click the Record button, this will start recording the test.



image



Type the url into the address bar http://localhost/Northwind/default.aspx and watch the good things happen, you will notice that the main pane of the application navigates to the desired url whilst the text box under the test name shows the WatiN test script required to achieve this functionality.



image



Simple eh? In my experience I have found that this tool is really good for the development of tests during the early stages of developing tests but as you get more used to the syntax of key words of WatiN your dependency on this tool becomes less and less, I would thoroughly recommend exploring this tool further to get a better understanding of the kinds of things that WatiN can do, however you will soon start to realise that the tests you are creating using this tool are not very reusable or maintainable.



At this point you need to start looking at a way to make your tests reusable and easily maintainable, I'll be giving you one way to do this in my next post in this series.

Wednesday 13 August 2008

Pigs and Chickens

So you are in an emerging agile team fighting against the ingrained waterfall style development that has existed for years, you are still in the early stages of getting everything working and feeling right, suddenly people are being referred to Pigs and Chickens but has anyone actually explained to you why? Well, it all comes from a story that Ken Schwaber started in the early days of Scrum, it goes something like this:

A chicken and a pig are brainstorming...

Chicken: Let's start a restaurant!

Pig: What would we call it?

Chicken: Ham n' Eggs!

Pig: No thanks. I'd be committed, but you'd only be involved!

"The real issue for a Scrum is who is committed to the project and accountable for deliverables. The committed get to talk at the daily Scrum meeting. They are the pigs and their butts are on the line. We could call them contributors if we don't like pig terminology. " - Jeff Sutherland

"People who are not committed to the project and are not accountable for deliverables at the meeting do not get to talk. They are excess overhead for the meeting. They might be called eavesdroppers if you don't like chickens. Whatever we call them it should have a negative connotation because they tend to sap productivity. They are really suckers or parasites that live off the work of others. Sorry to be political incorrect but others should come up with a euphemism that conveys the right balance between being "nice" and communicating clearly that eavesdroppers must minimize their impact on the productivity of the team. " - Jeff Sutherland

Read more on this in the following article by Jeff Sutherland which explains things in a little more detail: scrum pigs and chickens, also J.D. Meier has an interesting idea on how to turn chickens into pigs.