Hi Peter, Totally agree. We actually decided to keep the VS way and utilise those very search properties. I found it not very intuitive in comparison to the WatiN approach. So I built some extension methods on top of the UITestControl to search and find controls by any particular property. It was certainly faster than navigating the tree myself to find a particular control.
One thing I don't like, and not sure if its fixable, is that when you navigate to a new page, it doesn't wait before moving on in the code and trying to do your assertions, etc. In relation to the build server running the coded UI tests, in TFS2010 you get the whole lab management suite. We have some hyper-v instances run by Virtual Machine Manager and 4 machines are dedicated as our lab environment. These machines get the lab agent installed and are joined to the lab suite defined in the Microsoft Test and Lab Management application. When you create your build, you can use the workflow template for lab builds (this comes with TFS2010) and this gives you specific options for selecting which lab snapshot to rollback to, which build to use for lab testing, etc. Its really a part of the whole 2010 suite of products and for the most part works quite well. I just wish the coded UI tests were more like the WatiN ones. :) Steven Nagy Readify | Senior Developer M: +61 404 044 513 | E: [email protected]<sip:[email protected]> | B: azure.snagy.name<http://azure.snagy.name/> From: [email protected] [mailto:[email protected]] On Behalf Of Peter Gfader Sent: Thursday, 4 February 2010 11:06 PM To: ozTFS Subject: Re: Coded UI Tests >> 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<http://HtmlProperties.Button.Id>] = "ctl10_MainContentArea_ctl00_ctl00_CreateUserForm___CustomNav0_StepNextButtonButto" + "n"; this.mRegisterButton.SearchProperties[HtmlProperties.Button.Name<http://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]<mailto:[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<http://azure.snagy.name/> From: [email protected]<mailto:[email protected]> [mailto:[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]> [mailto:[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<http://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<http://azure.snagy.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
