Advanced test automation techniques for responsive apps and sites
•Als PPTX, PDF herunterladen•
0 gefällt mir•1,462 views
Slides from my talk on how to effectively test responsive apps and sites. The full video is available here: http://testautomation.applitools.com/post/148047224072/webinar-recording-advanced-test-automation
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von adamcarmi
Mehr von adamcarmi (12)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Advanced test automation techniques for responsive apps and sites
- 1. Adam Carmi (@carmiadam) Co-Founder and VP R&D at Applitools ADVANCED TEST AUTOMATION TECHNIQUES FOR RESPONSIVE APPS AND SITES
- 2. AGENDA What are responsive web sites? Let’s test Github! Best practices Q & A
- 3. RESPONSIVE WEB DESIGN An approach to web design aimed at crafting sites to provide an optimal viewing and interaction experience across a wide range of devices. “ WIKIPEDIA
- 7. LET’S TEST! + + +
- 8. INTERACTION TIPS Detect page layout within its page object Build browser and layout independent automation Avoid creating layout specific page objects Avoid detecting layout by window.innerWidth Set browser size by window.innerWidth
- 10. An approach to web design aimed at crafting sites to provide an optimal viewing and interaction experience across a wide range of devices. HOW CAN WE VALIDATE RWD??? “ WIKIPEDIA
- 11. VISUAL TESTING A quality assurance activity aimed to verify that a Graphical User Interface appears correctly to users
- 14. AUTOMATED VISUAL TESTING Drive the AUT and take screenshots Compare screenshots with baseline images Report differences Update the baseline
- 15. LET’S TEST! + + +
- 16. VALIDATION TIPS Prefer full page validation Use page object callbacks to validate layout-specific UI states Focus on lower layout boundaries Don’t abort your tests on validation failures Always use real browsers Prefer real devices
- 17. Adam Carmi (@carmiadam) Co-Founder and VP R&D at Applitools QUESTIONS?
Hinweis der Redaktion
- How to effectively test responsive web sites?
- As we have see with Github, the primary factor which affects the layout of the page is the browser’s width, or more accurately its inner width which does not include the browser window borders. The inner width is available in javascript as a property of the window object. Firefox: about:config layout.css.devPixelsPerPx;-1.0
- I’ll use C# for programming, Nunit to organize and execute the tests and Selenium for driving browsers. The reasons I chose C# are (1) because its my favorite programming language and I’m the speaker so I get to chose (2) there are not enough Selenium examples given in C# and (3) it is very similar to Java so no one should have any difficulty to follow the examples.
- First of all, you should detect the page layout within its page object. Different pages can have different layout modes and layout transition rules, and so the best place to encode those rules is within the page objects that represents them and not in your test code. Once you do that, you can implement generic tests that can interact with your responsive web site in any of its layout modes, and not having to update the tests when developers modify the layout transition. Furthermore, you should avoid creating a separate page object for each layout mode, but rather have a single page object that represents all the layouts modes of the page. This is the recommended approach because (1) the different layouts of the same page usually share the same page elements and only change their visibility and their position and size and (2) it allows you to reduce the number of page objects you need to maintain. The next tip suggest that you should avoid detecting the layout using the window.innerWidth property. Although your application relies on this property to switch layout modes, and you can easily access its value in your test code, if you rely on this property to detect the current layout, your tests will break whenever a developer changes the layout transition rules. The preferred way, is to detect the current layout by examining the state of the page elements, just like we did with checking the visibility of the navigation menu button to determine how to click the navigation buttons. Lastly, you should keep in mind that setting the browser width using selenium sets the width of the browser window which would result with a different window.innerWidth value for different browsers and operating systems because of the different width of the browser window borders. I will soon show you how to accurately set the inner width of the browser.
- How can we assure that page content is optimally displayed in all browsers devices screen resolutions and operating systems?
- Visual validation: impossible to accomplish this with element locators and property assertion with specific expected data for each screen size and browser Full page: (1) increased coverage (2) reduced maintenance overhead by not having to maintain element locators and deal with layout specific validation logic. Lower layout boundaries: (1) that’s where the bugs are (2) it exposes the worst and most dense representation of each layout mode Don’t abort: At the end of the test you have all new images to approve at once + ability to make use of automated maintenance. Real browsers: test against real layout engines and popular browser versions Real devices: browser and device emulators don’t emulate the UI perfectly: OEM additions, disappearing URL bar on scroll down affects height, common browser versions, UI rendering performance differences, etc.