while(availableTime>0) {

Stormwind.Accuracy - Part 2

Introduction

I've been toying around with the syntax for writing more natural acceptance tests as you can see here. So, while riding the 1h underground home, I was thinking on why I need to register all those components if their names should match (in some way) the key you are using in your acceptance test.

So let's take an example. Say I have a textbox called txtCustomerName. In the way that Accuracy is implemented right now, it can just guess your name from this string: "Customer Name", and in your acceptance test you'd write:

I.Fill("Customer Name").Textbox.With("Some Customer Name")

That does seem more natural than what I had before, and it's exactly what I'm trying to hit with Accuracy (catchy name huh?).

Current State

Right now, my acceptance tests read pretty much the same as they used to, but my DefaultPage class is a lot less cluttered:

   1:  public class DefaultPage : Page

   2:  {

   3:      public DefaultPage() : base("/default.aspx")

   4:      {

   5:          Register.Textbox("My Test Textbox 1");

   6:          Register.Label("My Test");

   7:      }

   8:  }

Note that you only need to Register controls that you want to check with ".And(I.SeeDefaultControls)" syntax.

You can skip control registration altogether if you'd rather check them all yourself like this:

   1:  .And(I.See("My Test Textbox 1").Textbox)

   2:  .And(I.See("My Test").Message)

I am close to a point where you won't even need to have page classes. You'd create only the pages you care about control registration.

As of now I have already implemented the following constructs (each level is a dot):

• I
  • GoTo("Page Key"); //Updates the current page to be the page with the key and navigate the browser to that URL.
  • Am("Page Key"); //Updates the current page to be the page with the key specified but does nothing to the browser. 
  • SeeDefaultControls; //Tests all controls registered in the current page to check they are visible.
  • See("Element Key")
    • Message; //Tests if the current page contains this text.
    • Button; //Tests if there's a button visible with this key.
      • IsLabeled("button label"); //Tests if there's a button with the given key and with the given label.
    • Textbox; //Tests if there's a textbox visible with this key.
      • ContainsText("text box text"); //Tests if there's a textbox with the given key and that contains the given text.
    • Checkbox; //Tests if there's a checkbox visible with this key.
      • IsLabeled("checkbox label"); //Tests if there's a checkbox with the given key and that a label exists for this checkbox with the given text.
      • IsChecked; //Tests if there's a checkbox with the given key checked.
      • IsNotChecked; //Tests if there's a checkbox with the given key unchecked.
    • Table; //Tests if there's a table visible with this key.
  • Fill
    • Textbox("Textbox Key")
      • WithText("some text"); //Fills the textbox with the given key with the given text.
  • Click("Element Key")
    • Button; //Clicks in the button with the given key.
    • Checkbox; //Clicks in the checkbox with the given key. If the checkbox is checked, unchecks it, otherwise check it.

Conclusion

So, that's the point where you are asking yourself: "Ok, this looks like magic, so where's the trick? How can he get from "Customer Name" to "txtCustomerName"? If it's fixed I don't want to use it! Who uses control prefixes these days, anyway?".

Well, you don't have to like the way I do my own controls :). That's fine. You can just implement your own INamingStrategy resolver and get whatever naming strategy you want. It has just one method to implement, so as long as you follow some convention in naming for your controls (you should anyway!) you'll be fine, whatever the convention is.

Actually, the more I think about it, the more I like it, since this actually forces me to have consistent naming all over the project!

Well, I'll try to churn some more code and get it usable before trying some more advanced scenarios.

Stay tuned to Accuracy news. Check out Claudio Figueiredo's blog (left sidebar) for Validation Everywhere news! He has finished the ValEver integration with Windsor, so if you are using a container and need to validate your method's arguments, that's for you!!!

#137