Book Image

How to Test a Time Machine

By : Noemí Ferrera
Book Image

How to Test a Time Machine

By: Noemí Ferrera

Overview of this book

From simple websites to complex applications, delivering quality is crucial for achieving customer satisfaction. How to Test a Time Machine provides step-by-step explanations of essential concepts and practical examples to show you how you can leverage your company's test architecture from different points in the development life cycle. You'll begin by determining the most effective system for measuring and improving the delivery of quality applications for your company, and then learn about the test pyramid as you explore it in an innovative way. You'll also cover other testing topics, including cloud, AI, and VR for testing. Complete with techniques, patterns, tools, and exercises, this book will help you enhance your understanding of the testing process. Regardless of your current role within development, you can use this book as a guide to learn all about test architecture and automation and become an expert and advocate for quality assurance. By the end of this book, you'll be able to deliver high-quality applications by implementing the best practices and testing methodologies included in the book.
Table of Contents (19 chapters)
Part 1 Getting Started – Understanding Where You Are and Where You Want to Go
Part 2 Changing the Status – Tips for Better Quality
Part 3 Going to the Next Level – New Technologies and Inspiring Stories
Appendix – Self-Assessment

The POM for UI automation

The POM is one of the best-known design patterns for writing test frameworks. It consists of separating the model (or test logic) from the pages (the declaration of objects and the locators of elements that those tests interact with). This allows the developer of the test code to find those objects and locators in an effortless way, rather than having to search all the instances of such objects across all the lines of code. The longest the test code, the more tedious this task becomes.

This model creates scalable and maintainable programs that can easily be changed if needed. While this is a good practice for any type of code (and could be considered part of the don’t repeat yourself (DRY) principle), it is especially critical for frontend test code, as the definition of locators and elements tends to change frequently.


DRY’s goal is to reduce the redundancy and repetition of software patterns, replacing them with abstraction or...