# Introducing CANDO-Test: A Framework for Structured UI Test Automation When someone you love takes a leap into the unknown, you find yourself inspired to build bridges. This framework was born out of one of those moments. My wife made the courageous decision to reinvent her life and pursue a new career in Test Automation. She didn’t come from a QA or IT background, and the world of testing tools, code, and best practices was entirely new to her. I watched her face that challenge with frustration at times, but also with remarkable resilience. That “can-do” attitude sparked something in me. What if I could create a clear, structured, and modular approach to UI automation—a set of guidelines and modular practices to help test engineers at any level build robust, maintainable, and scalable test systems with confidence? That’s how **CANDO-Test** came to life. > **CANDO-Test** stands for: > > * **C** – *Components*: The reusable building blocks representing UI parts and their behavior. > > * **A** – *Assessment*: Represents the evaluation logic—test cases designed to assess the system’s behavior under various scenarios. > > * **N** – *Network Emulation* (formerly "Network Mocks"): Tools and structures to simulate real-world network behavior and responses. > > * **D** – *Data Variant Creators*: Utilities for generating diverse sets of test input data. > > * **O** – *Objects (Page Object & Page Object Builder)*: Abstractions representing pages and flows, encapsulating how users interact with the system. > Each part of the acronym reflects a fundamental concept in modern UI test automation. Together, they form a scalable approach that emphasizes **clarity, modularity, reusability**, and **separation of concerns**. CANDO-Test is not a framework locked into Playwright, Selenium, or Cypress. It's a mindset—a way to structure your test code no matter the tool you use. ## The CANDO-Test Philosophy To support this mission, the CANDO-Test framework was created as a set of modular building blocks to bring clarity and structure to UI automation efforts. Each part of the framework—Components, Assessment, Network Mocks, Data Variant Creators, and Page Objects—plays a unique role in isolating responsibilities, encouraging reusability, and enabling engineers to build resilient test systems with confidence. Let’s explore what each of these elements means and how they work together: ### **Components** Is an abstraction that represents a distinct, reusable part of the user interface (UI) in the application. It encapsulates both the data (e.g., form fields values) and the actions (e.g., filling out a form, clicking buttons) related to that part of the UI. *Components* are used to interact with and verify behavior of specific UI elements. ### **Assessment** A self-contained, **purpose-driven scenario** or test goal. It defines the *what* and *why* of a test, leaving the *how* to lower layers like PageObjects and Components. An “Assessment” defines what you want to validate by combining data, mocks, and UI flows. It refers to a specific set of conditions and actions defined to verify the expected behavior of a system including the setup of necessary test data (such as data variants), interactions with the system (often through *PageObjects* or API calls), and the validation of outcomes. Implemented as “test case” that executes these steps and asserts that the actual results match the expected ones, ensuring the system behaves as intended under varios conditions. ### **NetworkMocks** It is responsable of constructs mocks for network requests (such as HTTP GET, POST, PUT, etc) to return predefined data or simulate different network behaviors )e.g., slow networks, timeouts, error response, etc). It provides a controlled environment by mocking network requests allowing tests to return predefined data. ### **Data Variant Creators** Is responsible for creating multiple variations or combinations of test data that will be used in testing. It handles the generation of different input values to test a wide range of scenarios and edge cases. It focuses on producing different sets of data that could be used across multiple test cases to test the system’s behavior under different conditions. It does not execute tests but is crucial for ensuring that various combinations of input data are tested. ### **Object (Page Object & Page Object Builder)** **PageObjects** Is an object that helps to organize interactions with specific pages in the application. This object encapsulates actions such as filling out forms, navigation between steps, and verifying user interaction outputs. *PageObject* facade abstracts actions related to specific user journey, provides methods to coordinate components and verify page states. **PageBuilders** It is used to construct and initialize complex page objects. It allows a structured and flexile approach to create instances of page objects by assembling their components. The *PageBuilder* should be only used to manage dependencies between different parts of the page (*components*) and to simplify the setup of *Assessments*. The PageObject and PageBuilder work together to provide a flexible and efficient approach to managing web page interactions in automated tests. While the **PageObject** handles the core functionality and logic, the **PageBuilder** simplifies the construction process, ensuring that the page object is instantiated with all necessary components, making the overall test setup more modular and easier to maintain. ## Layered Architecture The CANDO-Test framework follows a layered architecture to promote clean separation of concerns and composability: 1. **Foundation Layer** * Components * Network Mocks 2. **Data Layer** * Data Variant Creators 3. **Composition Layer** * Page Objects & Page Object Builders 4. **Test Logic Layer** * Assessment This structure helps you go from atomic actions to complete test flows with clarity. Each layer builds on the previous one, creating a clean hierarchy that scales with your application. ## Conclusion “CANDO-Test” is more than a framework, it's a mindset for designing well-structured, maintainable, and scalable UI test automation systems. As CANDO-Test focuses on architecture, does not matter whether you are just starting out or have years of experience in automation. It gives your test code a clean foundation, separates concerns, and encourages modular thinking. It's about building clarity into every layer of your test system, from atomic components to complex scenarios. In a field where speed often trumps structure, CANDO-Test is a reminder that well-designed automation pays off with faster onboarding, easier maintenance, and more resilient tests. Whether you're revamping a legacy test suite or setting a new standard for how UI testing should be done, the CANDO mindset helps you do it with confidence and with purpose. My wife’s journey inspired this. Maybe it can help someone else’s journey too. After all — **you CANDO it**.