WATIN also has the problem in that it can't automate non browser software. So 
if you want to open Outlook to assert than an e-mail with a particular subject 
was received you can't.

Mitch Denny
Chief Technology Officer
Readify Pty Ltd
Suite 408 LifeLabs Building | 198 Harbour Esplanade | Docklands | VIC 3008 | 
Australia
M: +61 414 610 141 | E: mailto:[email protected]

From: [email protected] [mailto:[email protected]] On Behalf Of 
Peter Gfader
Sent: Saturday, 6 February 2010 10:51 AM
To: ozTFS
Subject: Re: Coded UI Tests

                        > E.g. WATIN
                        >         private void WebsiteLoginToWebsite(string 
username, string password)
                        >         {
                        >             // Browse to login page
                        >             browser.Div(Find.By("innertext", "Member 
Login")).Click();
                        >
                        >  
browser.TextField(Find.ByName("ctl10$Header1$txtEmail")).TypeText(username);
                        >
                        >  
browser.TextField(Find.ByName("ctl10$Header1$txtPassword")).TypeText(password);
                        >             
browser.Button(Find.ByName("ctl10$Header1$btnLogin")).Click();
                        >         }

                        As an aside, piecemeal pushing and prodding of elements 
leads to very
                        brittle tests. You may like to look at WatiN's 
strongly-typed page
                        classes instead:

                        private void WebsiteLoginToWebsite(string username, 
string password)
                        {
                                      var page = browser.Page<LoginPage>();

                                      page.Email.TypeText(username);
                                      page.Password.TypeText(password);
                                      page.Login.Click();

                                      // etc
                        }

Sweeet!
I like that reuse of finding controls and the code is very nice and easy to 
read!

#1
But how does Watin find the "page.Email" in the example above?
   From your blog link I see:    get { return 
Document.TextField(Find.ByName("ctl10$Header1$txtEmail")); }
So is Watin just refactoring out these properties?

#2
What about var page = browser.Page<LoginPage>();
Does it get the current page and try to cast it into the LoginPage?
To myself: Reflector over this code...



                        More: 
http://watinandmore.blogspot.com/2009/06/introducing-page-class.html

                        > Create a coded UI test for a whole user interaction 
with your web app?
                        > e.g. Register, Login, Browse, Find, Add to Shopping 
cart, Update Billing
                        > Address, Update Shipping Address, Checkout, Pay, See 
Order successful
                        > Create a coded UI tests for single screens
                        > e.g. Logon screen: Assert "Username", "Password" 
boxes and "Login" button
                        > are there

                        An acceptance (UI) test should be written for each user 
story.

Disagree because that makes your test very fragile.
Agree, IF you have that as a "Done" criteria in your team.
  I would love to have these tests, but the time to create those and maintain 
those is my problem...


On Fri, Feb 5, 2010 at 7:13 PM, Richard Dingwall 
<[email protected]<mailto:[email protected]>> wrote:
On 5 February 2010 05:48, Peter Gfader 
<[email protected]<mailto:[email protected]>> wrote:
> E.g. WATIN
>         private void WebsiteLoginToWebsite(string username, string password)
>         {
>             // Browse to login page
>             browser.Div(Find.By("innertext", "Member Login")).Click();
>
>  browser.TextField(Find.ByName("ctl10$Header1$txtEmail")).TypeText(username);
>
>  
> browser.TextField(Find.ByName("ctl10$Header1$txtPassword")).TypeText(password);
>             browser.Button(Find.ByName("ctl10$Header1$btnLogin")).Click();
>         }
As an aside, piecemeal pushing and prodding of elements leads to very
brittle tests. You may like to look at WatiN's strongly-typed page
classes instead:

private void WebsiteLoginToWebsite(string username, string password)
{
       var page = browser.Page<LoginPage>();

       page.Email.TypeText(username);
       page.Password.TypeText(password);
       page.Login.Click();

       // etc
}

More: http://watinandmore.blogspot.com/2009/06/introducing-page-class.html

> Create a coded UI test for a whole user interaction with your web app?
> e.g. Register, Login, Browse, Find, Add to Shopping cart, Update Billing
> Address, Update Shipping Address, Checkout, Pay, See Order successful
> Create a coded UI tests for single screens
> e.g. Logon screen: Assert "Username", "Password" boxes and "Login" button
> are there
An acceptance (UI) test should be written for each user story.

--
Richard Dingwall
http://richarddingwall.name
_______________________________________________
oztfs mailing list
[email protected]<mailto:[email protected]>
http://prdlxvm0001.codify.net/mailman/listinfo/oztfs

_______________________________________________
oztfs mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/oztfs

Reply via email to