> 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]>wrote:
> On 5 February 2010 05:48, Peter Gfader <[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]
> http://prdlxvm0001.codify.net/mailman/listinfo/oztfs
>
_______________________________________________
oztfs mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/oztfs
