A Test Should Tell You Where It Failed, Not Just That It Failed
A test can return a failed status without explaining what went wrong. In a long workflow, finding the cause may mean retracing dozens of actions, reviewing logs, and reproducing the failure.
Test Blocks by TestZeus addresses this challenge by breaking tests into individual steps that can be executed, inspected, and verified. Testers can record browser interactions, edit captured actions, add assertions and conditional logic, combine UI workflows with API or SOQL checks, and inspect evidence from execution.
Build Tests as Individual Steps
Test Blocks structures test cases into individual, manageable steps rather than treating the entire workflow as one sequence. Each step represents an action or check within the test, making the workflow easier to organize and inspect.
When creating a new test, users can select Test Blocks, choose an environment, and start building their test. Browser interactions can be recorded as individual steps, allowing each action to become part of the test case.
For example, a Salesforce account-creation test can include separate steps for opening the Accounts tab, selecting New, entering account information, and saving the record. These steps form a single workflow while remaining individually accessible.
During execution, Test Blocks runs and verifies each step, providing visibility into how the test progresses. If a step encounters a problem, users can identify the specific point that requires attention instead of relying only on the final test status.
This step-based structure makes it easier to review individual actions and understand how they contribute to the overall test.
Record Browser Actions and Refine the Test
Test Blocks supports browser recording to help users create test cases from application interactions. As actions are performed in the browser, the corresponding steps are added to the test.
However, recorded interactions may include actions that are not required for the intended test. An accidental click or unnecessary scroll, for example, can become part of the recording even though it does not contribute to the scenario being tested.
Test Blocks allows users to pause recording, remove unwanted steps, and resume recording when they are ready to continue. This provides control over which actions remain in the final test case.
Users can also record multiple parts of a workflow within the same test. An account-creation scenario can be extended to create a contact, bringing related actions together in one place.
The result is a test that can be refined after recording, with irrelevant actions removed and the steps needed for the intended workflow retained.
Turn Recorded Actions Into Verifiable Outcomes
Performing an action and verifying its result are different parts of a test. Clicking Save does not, by itself, establish that a record was created successfully.
Test Blocks supports assertion steps so users can define what the test should verify. For example, after creating an account, a tester can add an assertion to check whether the account was created.
Assertions make the expected outcome part of the test rather than leaving success to be inferred from the completion of browser interactions.
This capability allows users to add checks alongside recorded actions and define what needs to be verified within the workflow.
By including explicit assertions, a test can check more than whether its actions ran. It can also verify whether the expected result was achieved.
Use Conditional Logic to Control Test Execution
Not every step needs to run in every scenario. Some actions depend on values or conditions that determine whether they are relevant to the current test.
Test Blocks supports conditional logic, allowing users to group steps within an if condition. Selected steps can be wrapped in a conditional block, with execution dependent on the condition defined by the user.
For example, a group of actions can run only when an account name contains a specified value. If the condition is not satisfied, those wrapped steps do not run.
Users can add steps to the conditional block by moving them into it or by selecting existing steps and wrapping them in an if statement.
This makes it possible to define conditional behavior directly within a test case, rather than requiring every action to execute unconditionally.
Combine UI Testing With API and SOQL Checks
Test Blocks supports both browser-based interactions and API or SOQL testing within a test workflow.
Browser steps allow users to interact with the application, while API or SOQL steps can be added when a check does not require a browser. This allows different types of verification to exist within the same test.
For example, a Salesforce test can create an account through the browser, add a contact, and include a separate API or SOQL step to check the resulting information.
During execution, the API step provides response evidence. The demonstrated workflow shows an HTTP 200 response along with the account information returned by the request.
Users can inspect this evidence to review the response and the relevant data. The expected result still needs to be checked against the test requirement; a successful HTTP response alone does not establish that every business condition has been satisfied.
By supporting UI and API or SOQL steps together, Test Blocks provides a way to build test cases that include both browser interactions and additional data checks.
Inspect Step-Level Evidence During Execution
Test Blocks provides evidence that helps users inspect what happened during a test run.
As individual steps execute, users can review their verification status and the proof associated with each step. For browser actions, this can include screenshots showing the action performed and the resulting application state.
Test Blocks also provides an execution video, allowing users to review the sequence of actions. For advanced users, generated code is available for individual steps, providing another way to inspect how those steps were represented.
These capabilities offer different views of the same execution:
Step verification: Review whether an individual step has been verified.
Screenshots: Inspect visual evidence associated with a step.
Execution video: Review the sequence of actions during the run.
Generated code: Examine the code associated with individual steps.
This step-level visibility makes the execution process easier to inspect and gives users more information when investigating a problem.
Automatic Healing for Steps That Encounter Problems
Test Blocks includes an auto-healing capability for steps that encounter problems during execution.
When a step requires healing, the execution interface displays the healing attempt and its progress. The demonstrated process shows up to five attempts to auto-heal a step.
This capability allows the system to attempt recovery when an action encounters a problem, rather than immediately treating every issue as an unrecoverable failure.
Users can observe the healing process through the execution interface and review the resulting step status and available evidence.
Auto-healing does not remove the need to verify the intended outcome. A step that recovers still needs to produce the expected result, and the associated evidence remains important when reviewing the execution.
Generated Code and Python Support
Test Blocks provides generated code for individual steps, giving advanced users an additional way to inspect how their test actions are represented.
Users can open the code view for a step and review the code generated for that action. This is available alongside the step-level execution proof, allowing users to inspect both what happened during execution and the code associated with the step.
For users who prefer writing code directly, Test Blocks also supports Python code as an alternative to writing instructions in natural language.
These options provide flexibility for users with different levels of technical experience and different preferences for working with tests.
One Test Workflow With More Visibility and Control
Test Blocks by TestZeus brings test authoring, step-level execution, assertions, conditional logic, UI and API or SOQL checks, and execution evidence into one workflow.
Users can record browser interactions, remove unnecessary actions, define conditions, add assertions, inspect generated code, and review proof for individual steps. The auto-healing capability provides additional recovery attempts when a step encounters a problem.
By making each step accessible for inspection and verification, Test Blocks provides a more structured way to build and review automated tests.
A useful test should do more than report a final status. It should make the actions, checks, and results behind that status visible.
Explore TestZeus to learn more about its approach to AI-powered test automation.
Frequently Asked Questions
What are Test Blocks by TestZeus?
Test Blocks is a feature for creating and running tests as individual steps, with support for recorded browser interactions, assertions, conditional logic, API or SOQL checks, and execution evidence.
How do Test Blocks help debug tests?
Testers can inspect individual steps and review evidence such as screenshots, execution video, and generated code instead of relying only on the final test status.
Can Test Blocks support API testing?
Yes. The demonstrated workflow supports API or SOQL steps alongside browser-based actions, allowing testers to inspect responses and verify relevant data.
Does Test Blocks support auto-healing?
The walkthrough demonstrates automatic healing attempts, showing up to five attempts for a problematic step. The expected outcome should still be verified after recovery.
// Start testing //
