CANDO-Test: Rules

Building automated tests can be tricky, especially when working on large projects. You need a structure that keeps things simple and easy to maintain. That's where the CANDO-Test framework comes in. It helps organize and simplify UI testing by breaking things down into smaller, reusable parts. But a framework is only as strong as the rules it follows. In this article, we’ll explore the rules that guide the CANDO-Test framework, ensuring your tests are clear, flexible, and easy to manage.

These rules aren’t just suggestions—they’re key principles that help keep the testing process efficient and organized. Each rule has a specific purpose, designed to improve how we write and manage tests. Let’s take a closer look at these rules and understand why they matter.

Rules

Rule 1: Assessment Drives Behavior, Not Structure

Assessments are agnostic to the Page Structure. They do not directly interact with individual components or know how the page is constructed; They only interact with higher-level actions exposed by the Page Object, Builders, Data Variant Creators or Network Mocks.

💡Why It Matters:
This improves modularity, reduces test fragility, and separates the test logic from the UI details.

✅ Do:

• Keep assessments focused on test goals and behaviors.

• Use higher-level methods from Page Objects and Builders e.g: Use registerUser() on the Page Object instead of interacting with form fields directly.

❌ Don’t:

• Let Assessments interact directly with the page structure or components.

• Write low-level UI selectors like click('#submit-button') inside the Assessment (test case).

Rule 2: Let Page Objects Speak in User Language

Page Objects should only expose meaningful user actions (like "submitForm" or "goToNextStep"). They should not expose tiny details like button clicks or text inputs. Those details live in the Components.

💡 Why It Matters:
By focusing on user-centric actions, Page Objects are more intuitive and resilient to UI changes, making tests clearer and easier to maintain.

✅ Do:

• Use high-level actions like “submitForm” in your tests.

• Keep Page Objects abstract and aligned with user journeys.

❌ Don’t:

• Expose low-level interactions like clicking a button or typing in a field in the Page Object.

Rule 3: Reuse Before You Rewrite

Use Components, Data Variant Creators, and Page Builders to create reusable blocks. If something already exists, don’t rebuild it. Reuse keeps your project smaller and simpler.

💡 Why It Matters: Reusing existing pieces minimizes redundancy, ensuring the test suite stays smaller, simpler, and easier to maintain.

✅ Do:

• Reuse existing functionality to build your tests.

• Leverage reusable components and Page Builders for efficient test creation.

❌ Don’t:

• Rewrite code when reusable parts already exist.

Rule 4: Don’t Overbuild the UI Pieces

Not every little button or label needs a special Component. Too many small components make your project harder to manage. Keep it balanced—only make components when they have logic or need to be reused.

💡 Why It Matters:
Too many tiny components create unnecessary complexity and maintenance overhead.

✅ Do:
Group related elements into logical components when needed.

❌ Don’t:

• Make a separate component for a static label or a basic link.

• Overbuild components for simple UI elements that don’t require abstraction.

Rule 5: Keep Test Data Flexible and Centralized

Use Data Variant Creators to build test data. Don’t put data directly inside tests. This makes it easier to test many cases without changing the test steps.

💡 Why It Matters: Centralizing data creation allows for more extensive testing with different inputs while keeping the Assessments (test cases) clean and easier to manage.

✅ Do:

• Use Data Variant Creators for generating various sets of test data.

• Keep test data separate from test logic for flexibility.

❌ Don’t:

• Hard-code test data inside test cases or assessments.

To wrap things up, here are a few key best practices to keep in mind while using the CANDO-Test framework:

• Page Objects should focus on user actions: Let them handle high-level interactions (like "submit the form" or "navigate to a different page"), and leave detailed UI interactions (like clicking buttons or typing text) to Components.

• Avoid creating overly granular components: Not every small UI element needs its own component. Components should only be made for elements that have reusable logic or behaviors, to avoid clutter and complexity.

• Keep components simple and reusable: Don’t break everything down into tiny, low-level UI details unless absolutely necessary. Combine components when possible to keep the system simple and maintainable, without losing reusability.

Conclusion

The CANDO-Test framework is built on strong, simple rules that help keep tests clean, flexible, and easy to maintain. By following these guidelines, you ensure that your tests will remain adaptable and easy to work with as your application grows and changes. By focusing on clarity, reusability, and flexibility, the framework helps you write tests that are both powerful and easy to manage, making your job as a tester easier in the long run.