>> One of the things I’ve found is that the VS coded UI tests replicate
large chunks of the page in code.
>> For example, it creates classes for the DOM, window, divs, tables, etc.
These are all strongly typed classes that represent your exact div or table.
>> Typically an assertion might only care that the date on the screen is
valid, not where it sits in the structure of the page.
VS doesn't create strictly classes for the whole DOM tree but it finds
controls by looking at different properties.
Look at the below coded UI test from a web app
public void CodedUITestMethod1()
{
-- SNIP SNIP SNIP --
this.UIMap.ClickonRegister();
-- SNIP SNIP SNIP --
}
ClickonRegister method has a button
public void ClickonRegister()
{
#region Variable Declarations
HtmlInputButton registerButton =
this.PeterGfaderWhWindow.HttpsswcomaupClient.PetersofGfaderSiDocument.RegisterButton;
#endregion
// Click 'Register' button
Mouse.Click(registerButton, new Point(39, 17)); --> this Point
is inside the button, relative to button top left corner!
-- SNIP SNIP SNIP --
}
This button "registerButton" is found via the following SearchProperties
public HtmlInputButton RegisterButton
{
get
{
if ((this.mRegisterButton == null))
{
this.mRegisterButton = new HtmlInputButton(this);
#region Search Criteria
this.mRegisterButton.SearchProperties[
HtmlProperties.Button.Id] =
"ctl10_MainContentArea_ctl00_ctl00_CreateUserForm___CustomNav0_StepNextButtonButto"
+
"n";
this.mRegisterButton.SearchProperties[
HtmlProperties.Button.Name] =
"ctl10$MainContentArea$ctl00$ctl00$CreateUserForm$__CustomNav0$StepNextButtonButto"
+
"n";
this.mRegisterButton.FilterProperties[HtmlProperties.Button.DisplayText] =
"Register";
this.mRegisterButton.FilterProperties[HtmlProperties.Button.Type] =
"submit";
this.mRegisterButton.FilterProperties[HtmlProperties.Button.Title] = null;
this.mRegisterButton.FilterProperties[HtmlProperties.Button.Class] = null;
this.mRegisterButton.FilterProperties[HtmlProperties.Button.ControlDefinition]
= "id=ctl10_MainContentArea_ctl00_ctl00_Cre";
this.mRegisterButton.FilterProperties[HtmlProperties.Button.TagInstance] =
"40";
this.mRegisterButton.WindowTitles.Add("Peter Gfader |
Sign Up - Windows Internet Explorer");
#endregion
}
return this.mRegisterButton;
}
}
*I think these search properties ARE TOO STRICT*
I would probably change this generated code to be only:
this.mRegisterButton.FilterProperties[HtmlProperties.Button.DisplayText] =
"Register";
this.mRegisterButton.FilterProperties[HtmlProperties.Button.Type] =
"submit";
Maybe VS gives us the option on how strictly it shoud find the controls...
>> When the UI guys get their hands on a page and change things around, even
slight changes cause a bunch of tests to fail.
>> Even changing the title of the page has drastic consequences!
Yes, I think we should create the generated code from the Coded UI as a
starting point and modify it to our needs.
Sounds not very practical though ;-)
@Steven ...*curios...*
How did you setup the build server to run the coded UI tests?
I didn't try it but I heard its not sooooo easy... Do you have some blog
posts or hints to share?
.peter.gfader.
http://peitor.blogspot.com/
On Mon, Feb 1, 2010 at 12:15 PM, Steven Nagy <[email protected]>wrote:
> Yep that framework looks like it does the same sorts of things as WatiN.
>
>
>
> I guess before I jump ship I just want to make sure the VS coded UI tests
> can’t do the same thing.
>
>
>
> *Steven Nagy
> *Readify | Senior Developer
>
> M: +61 404 044 513 | E: [email protected] | B: azure.snagy.name
>
>
>
> *From:* [email protected] [mailto:[email protected]] *On
> Behalf Of *Brian Whitehorn
> *Sent:* Monday, 1 February 2010 11:08 AM
> *To:* 'ozTFS'
> *Subject:* RE: Coded UI Tests
>
>
>
> Hi,
>
>
>
> I haven’t used myself (_yet_), so not sure if it’ll meet all you require,
> but have you looked at Webaii?
>
> http://www.artoftest.com/support/webaii/topicsindex.aspx
>
> Looks it could fit to what you describe. HTH.
>
>
>
> Cheers,
>
> Brian.
>
>
>
> *From:* [email protected] [mailto:[email protected]] *On
> Behalf Of *Steven Nagy
> *Sent:* Monday, 1 February 2010 11:55 AM
> *To:* ozTFS
> *Subject:* Coded UI Tests
>
>
>
> Hi all,
>
>
>
> We use TFS2010 with the full lab management bit, running coded UI tests as
> part of the nightly build.
>
>
>
> One of the things I’ve found is that the VS coded UI tests replicate large
> chunks of the page in code.
>
> For example, it creates classes for the DOM, window, divs, tables, etc.
> These are all strongly typed classes that represent your exact div or table.
>
>
>
> We’re finding this kind of structure very inflexible. Typically an
> assertion might only care that the date on the screen is valid, not where it
> sits in the structure of the page.
>
> When the UI guys get their hands on a page and change things around, even
> slight changes cause a bunch of tests to fail. Even changing the title of
> the page has drastic consequences!
>
>
>
> We’re looking at using WatiN instead (watin.sourceforge.net) because it
> lets you just ask for a control by name or id. This means we can find
> anything we want to validate, click, or enter text for, without having to
> care where on the page it is.
>
> But before we dive down this route, is this something that the existing
> coded UI tests will let us do? I can’t see how but that doesn’t mean its not
> there.
>
>
>
> Our app is very flexible and the UI constantly changes. This shouldn’t mean
> we have to defer testing until the very end.
>
> Appreciate any tips or advice on proceeding with the OOTB tooling.
>
> *Steven Nagy
> *Readify | Senior Developer
>
> M: +61 404 044 513 | E: [email protected] | B: azure.snagy.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
