The Habits That Make Our Tests More Reliable

Map the journey before writing the test

Before we automate a step, we need to understand where it begins and where it ends. A visitor may submit a form on a website, but the data can originate in a CMS or CMA, travel through the UI, arrive in Eloqua, and support segmentation, campaign reporting, or downstream systems such as Salesforce.

Mapping the whole path changes the test design. It shows which risk belongs in the browser, which belongs in an API or integration check, and which values need to remain consistent across systems. Without that view, we can test a successful form submission while missing the campaign source, consent value, or content identifier that never reaches Eloqua.

Start with risk, not test count

We do not measure a suite by how many tests it contains. We look at the risk it protects. A gated-content form deserves attention because its failure can affect lead capture, campaign attribution, and company KPIs.

A useful test confirms both the visitor-facing result and the data result. The first assertion protects the experience. The second confirms that the information needed by the campaign exists where it should.

await page.getByLabel('Email').fill('test@example.com');
await page.getByRole('button', { name: 'Download guide' }).click();

await expect(
  page.getByText('Your download is ready')
).toBeVisible();

const contact = await eloquaApi.findContact('test@example.com');

expect(contact.fieldValues).toMatchObject({
  emailAddress: 'test@example.com',
  campaignSource: 'download-guide',
  consent: 'true',
});

Use the fastest feedback loop available

A browser test should not be the first place we discover every broken field mapping or invalid payload. Unit tests can verify local transformation logic. API and integration tests can check required fields, error handling, and the contract between systems.

Playwright is most valuable when the browser contributes risk that those checks cannot cover: validation rules, consent interactions, content variants, hidden fields, and the handoff from a page into a marketing flow. That keeps feedback close to the change and makes failures cheaper to investigate.

Run the right tests at the right CI/CD stage

Running every browser test on every pull request can make feedback slow. Skipping browser checks until after merge can leave critical failures too late.

A tiered pipeline gives us a better balance. Run unit and API tests on every pull request. Run a small Playwright smoke suite for critical journeys, such as lead capture or sign-in. Run broader E2E coverage after merge, on a scheduled run, or before a release. The exact split depends on the application and deployment frequency, but the principle stays the same: give developers fast feedback first, then build confidence in the integrated system.

Make tests independent and data intentional

Shared test accounts create failures that are hard to explain. One test changes a contact record; another assumes that contact is new. A test passes in isolation but fails after a campaign runs against the same environment.

Each test should create the state it needs and use data that belongs to that run. If we need a contact from a specific campaign, we create it with a unique identifier and verify its record directly. That removes assumptions about execution order and stale data.

Treat the UI and data as contracts

The UI has a contract with visitors and with the systems that rely on the information it collects. Semantic locators make the visitor-facing contract clear, while accessible labels and controls make the interaction easier to understand and maintain.

The data contract matters just as much. If the CMS or CMA supplies a campaign identifier, the UI must submit it correctly, and Eloqua must store it in a form that supports attribution and segmentation. A lead with missing campaign data may still exist, but it no longer tells us which campaign generated it.

await page.getByRole('checkbox', {
  name: 'I agree to receive marketing communications',
}).check();

Make failures explain themselves

Imagine a test that submits a campaign form. The screenshot shows the success message, so the visitor-facing interaction completed. The test record includes a unique email address and correlation ID. When we look up the contact in Eloqua, the contact exists but campaignSource is blank.

That evidence narrows the problem. The UI may have sent the wrong hidden field; the CMS or CMA may have published incorrect metadata; or an integration may have transformed the payload incorrectly. The problem is no longer reported as a generic form failure. It points to a specific break in the flow and helps the right team investigate.

Traces, screenshots, request payloads, responses, and system records turn a failed test into useful feedback.

Build trust in the signal

The target is a suite people trust when making release decisions. We build that trust by reviewing recurring failures, removing checks that no longer protect meaningful risk, fixing weak test-data setup, and keeping evidence close to each failure.

Playwright gives us strong browser automation. The confidence comes from the system we build around it: clear risk, fast feedback, intentional data, and evidence that helps us act on failures.