The Page Object pattern #44
Conversation
…attern used when writing UI tests.
…tern used when writing UI tests.
…ity of 'ScreenComponent' when it comes to HTML applications.
…attern used when writing UI tests.
…tern used when writing UI tests.
…ity of 'ScreenComponent' when it comes to HTML applications.
…cFiasco/cuite into page-and-screen-objects
…ctionality to 'ControlBaseFactory' instead.
…tests for rebased page components, mainly because Silverlight not nativly supports group boxes.
…lling 'BrowserWindow' was sufficient.
…ade to it anymore.
… instead of 'BrowserWindowUnderTest'.
… 'Browser' on 'PageComponents' that contains the control that launched the screen and page.
…for Silverlight. Will add tests for HTML later.
| /// <summary> | ||
| /// Represents a audio control for web page user interface (UI) testing. | ||
| /// </summary> | ||
| public class HtmlAudio : HtmlControl<CUITControls.HtmlAudio> |
There was a problem hiding this comment.
Unfortunately, HtmlAudio is not available in Microsoft.VisualStudio.TestTools.UITesting.HtmlControls for Visual Studio 2010. Neither is HtmlMedia and HtmlSlider.
|
I'm on it. I went to bed right after creating the PR last night. |
… for Visual Studio 2010 since those controls aren't supported for that version.
|
And the build is finally green. I'll continue to merge the PR as soon as you say so. |
|
Yes, you can go ahead and merge. We should try to keep the new CHANGELOG.md up to date as well. Thank you. |
|
I'll update the CHANGELOG.md before I merge. Do you wan't me to follow any specific syntax or format when I write new entries in the file? E.g. this article specifies numerous guidelines when it comes to changes, do we wish to embrace any of them? |
|
That article has some good points. I'm flexible and open to change, but I agree there should be some consistency, and especially readability. Thank you. |
Merged implementation of the Page Object pattern.
Introduction
This PR re-implements the Page Object pattern in CUITe.
The support for the pattern was previously implemented by the classes
BrowserDialogUnderTest,BrowserWindowUnderTestandDynamicBrowserWindowUnderTest, but some features where lacking and no corresponding support existed for desktop applications.Meet the
CUITe.ObjectRepositoryNamespaceA new namespace called
CUITe.ObjectRepositoryhas been added that directly focuses on the Page Object pattern.The following classes support tests written for the browser:
PagePageComponentPageComponent<T>The corresponding classes for desktop are called:
ScreenScreenComponentScreenComponent<T>A page or screen component is a composite part of a page or a screen. If a page or screen is complex to model in a UI test, the page or screen can be divided into separate composite components, each representing a part of the UI.
E.g. a header or footer in a web application can exist on numerous pages, and by representing it as a component within the page the DRY principle can be respected. It also means that if the e.g. header change in the web application, updating the page component should be sufficient in order to pass all failing tests, since all test share the same header component.
Changes in the PR
Most of the changes in the PR are refactoring of existing UI tests to use the new classes instead of the old. Only a few classes have been added to the CUITe project, most other additions are new test projects that exercise the new Page Object classes.
Final Thoughts
This feature was one of my main goals when joining the project. I think the support for writing robust UI tests has increased with this PR. I will continue to work on a final feature called Workflows that combines common tasks spanning multiple pages or screens into unique test classes. After that I will focus on getting us ready for a official 2.0 version, but will require your help for that.