Skip to main content

Pillars of successful test automation

The Pillars of successful test automation are Scalability, Reliability, and Maintainability. SHAFT supports them by keeping test intent in the test code and moving browser, mobile, API, evidence, configuration, and recovery mechanics into one engine.

Scalability​

Scalability means the framework can add browsers, devices, environments, and test volume without forcing every test class to fork. SHAFT does this by putting execution choice behind configuration and keeping the test body on the same facade.

SHAFT supportWhat it enables
WebDriver and Playwright backendsChoose Selenium/Appium WebDriver or Playwright per test setup while keeping SHAFT GUI actions.
Web, mobile, API, CLI, database, and test data namespacesKeep different test surfaces in one framework instead of separate helper stacks.
TestNG, JUnit, and Cucumber integrationUse the runner that fits the project and CI pipeline.
TestNG parallel settings and ThreadLocal driver patternRun independent test methods, classes, suites, or data providers in parallel without sharing a driver instance.
SHAFT.CrossBrowserModeRun the same browser test class against Chrome, Firefox, and Safari sequentially or in parallel when Docker is available.
executionAddressMove the same test code from local execution to Docker, Selenium Grid, BrowserStack, Appium, or another remote WebDriver endpoint.
headlessExecution and maximumPerformanceModeReduce desktop browser overhead when the suite needs faster CI feedback.
shaft-bom and optional modulesAdd heavy capabilities such as Visual, Video, Heal, BrowserStack SDK, Capture, Doctor, MCP, or AI providers only when the project needs them.
src/main/resources/properties/custom.properties
executionAddress=localhost:4444
targetOperatingSystem=Linux
targetBrowserName=chrome
headlessExecution=true
SHAFT.CrossBrowserMode=parallelized

Reliability​

Reliability means a passing test represents a real pass and a failing test carries enough evidence to explain the failure. SHAFT reduces accidental flakiness by centralizing waits, retries, reports, and validation behavior.

SHAFT supportWhat it protects
Element lookup timeout and fluent waitsElement actions retry until the element is available instead of relying on sleeps in every test.
Browser lazy-loading waitsBrowser actions can wait for document readiness, network quiet time, jQuery, and Angular signals when the page exposes them.
Explicit condition waitsTests can wait for business states such as a status value, count, URL, title, or spinner state.
Fluent assertions and verificationsUI, API, file, number, object, and schema checks use one reporting path.
Retry analyzer and JUnit extensionRetries are opt-in and bounded by retryMaximumNumberOfAttempts.
Retry evidence captureforceCaptureSupportingEvidenceOnRetry=true enables richer evidence on retry attempts.
Allure report integrationActions, logs, screenshots, request/command evidence, and attachments are grouped with the test result.
SHAFT DoctorFailed-run evidence can be packaged and diagnosed without relying on a live provider by default.
src/main/resources/properties/custom.properties
defaultElementIdentificationTimeout=10
waitForUiStateTimeout=600
retryMaximumNumberOfAttempts=1
forceCaptureSupportingEvidenceOnRetry=true
screenshotParams_whenToTakeAScreenshot=ValidationPointsOnly
reporting.attachFullLog=true

Use explicit waits for application states that the browser cannot infer:

ReliableStateWait.java
driver.browser().navigateToURL("https://example.test/orders");
driver.element().click("Refresh orders");
driver.element().waitUntilElementTextToBe(By.id("sync-status"), "Complete");
driver.assertThat(By.id("order-count")).text().isEqualTo("25");

Maintainability​

Maintainability means product changes require small, obvious test updates. SHAFT helps by making tests describe user intent, keeping configuration outside test logic, and supporting common automation design patterns.

SHAFT supportWhat it keeps maintainable
SHAFT facadeTest code uses one entry point for GUI, API, CLI, DB, test data, properties, reporting, and validations.
Fluent action chainsTests and page objects read as workflows instead of low-level WebDriver calls.
Page Object Model and thin base-class patternsLocators, page actions, and lifecycle setup stay in predictable places.
Smart LocatorsinputField(...) and clickableField(...) target user-facing labels, text, placeholders, and ARIA signals.
Locator BuilderComplex locators can be composed fluently instead of handwritten XPath strings.
Native WebDriver accessTeams can drop to Selenium/Appium APIs only when a specialized case needs it.
External test dataJSON, CSV, Excel, YAML, and properties files keep data and environment values out of test methods.
Programmatic and file-based propertiesEnvironment changes can be made through properties or Maven -D overrides.
Optional SHAFT HealWeb locator recovery is explicit, trust-gated, reported, and kept separate from normal test code.
MaintainableLoginTest.java
public class LoginTest {
    private SHAFT.GUI.WebDriver driver;
    private SHAFT.TestData.JSON users;

    @BeforeMethod
    public void setUp() {
        driver = new SHAFT.GUI.WebDriver();
        users = new SHAFT.TestData.JSON("testData/users.json");
    }

    @Test
    public void userCanLogIn() {
        driver.browser().navigateToURL("/login");
        driver.element()
                .type(SHAFT.GUI.Locator.inputField("Email"), users.getTestData("valid.email"))
                .type(SHAFT.GUI.Locator.inputField("Password"), users.getTestData("valid.password"))
                .click(SHAFT.GUI.Locator.clickableField("Log in"));
        driver.assertThat().browser().url().contains("/dashboard");
    }

    @AfterMethod(alwaysRun = true)
    public void tearDown() {
        driver.quit();
    }
}

Choosing Features By Pillar​

If the team needs...Start with...
Faster CI feedbackTestNG/JUnit parallel execution, ThreadLocal drivers, headless execution, and remote Grid capacity.
Wider platform coverageexecutionAddress, targetOperatingSystem, targetBrowserName, BrowserStack, Appium, and CrossBrowserMode.
Less UI timing noiseBuilt-in synchronization, explicit waits, and a low retry budget with retry evidence.
Better failure triageAllure evidence, screenshots, full logs, retry artifacts, Doctor, video, and Playwright tracing where used.
Lower selector churnSmart Locators, ARIA locators, Locator Builder, Page Objects, and optional SHAFT Heal.
Cleaner test data changesSHAFT.TestData with JSON, CSV, Excel, YAML, or properties files.
Smaller dependency footprintshaft-engine plus only the optional SHAFT modules the project actually uses.