Frontend integration

Validate a Conduit frontend

Run the shared frontend compatibility checks and separate UI behavior from API conformance.

Validate a Conduit frontend against the shared Playwright end-to-end surface, then identify which failures belong to the UI contract and which belong to the API. The suite checks browser-visible behavior and selectors; it is not a replacement for the backend API conformance tests.

Before you begin

You need a running frontend, a test API environment, and a Playwright project that can load the shared test files. Extend the shared base Playwright configuration with your application's baseURL and webServer settings. Use isolated test data where your API permits it; the reference tests generate unique users and articles for their workflows.

ℹ️The shared E2E suite covers frontend compatibility. Backend developers should also run the API behavior suites, such as Hurl, when they need to prove status codes, envelopes, validation, and permissions.

Run the compatibility checks

Set the frontend base URL

Configure Playwright's baseURL to the address where your frontend is running and configure webServer if the test runner must start it.

import { defineConfig } from "@playwright/test";

export default defineConfig({
  use: { baseURL: "http://localhost:4200" },
  webServer: { command: "npm run start", url: "http://localhost:4200" },
});

The runner can resolve relative page navigation against your frontend instead of the shared example application's host. Replace the command and port with values supported by your project.

Run authentication coverage

Run the authentication tests and inspect the browser-visible results. The shared coverage registers a user, confirms a redirect to /, checks the profile link, opens /editor, logs in again after logout, checks invalid credentials, and verifies that an unauthenticated visitor cannot remain on /editor.

bash

npx playwright test specs/e2e/auth.spec.ts

Passing tests show the expected route changes, links, and .error-messages behavior. A failure here is usually a frontend route, form, selector, or session integration issue; inspect the request only after confirming the UI action occurred.

Run article workflow coverage

Run the article tests with a logged-in user. They create an article, verify its URL and rendered title, body, and tags, update its title, and delete it.

bash

npx playwright test specs/e2e/articles.spec.ts

Passing tests show the article workflow is reachable from the UI and that the rendered article data matches the submitted values. The suite obtains the article slug from the resulting URL rather than assuming a fixed identifier.

Exercise error states

Run the error-handling tests or reproduce their cases with request interception. The suite checks that mocked 500 responses and network failures for feeds, tags, profiles, and article details leave the navigation and page containers usable.

bash

npx playwright test specs/e2e/error-handling.spec.ts

Passing tests show that an API failure does not crash the page. For example, a failed tags request should leave the navbar, banner, and feed toggle available while the feed response remains usable.

Classify failures by boundary

For each failed test, record whether the browser sent the expected request, whether the API returned the expected contract, and whether the frontend rendered the required result. Use the frontend suite for routes, controls, selectors, and resilient error states; use backend conformance for API status codes and payload behavior.

The result is a failure report that points to one boundary instead of treating every red test as an API defect.

Verify the result

✅A frontend validation run is meaningful when authentication, article workflows, and error handling complete against the configured baseURL, and every failure has been classified as a UI compatibility issue, a transport issue, or an API contract issue.

Limitations

The shared suite demonstrates required compatibility behavior, but the cited coverage is not a complete application test plan. Add tests for product-specific behavior and use the API contract tests for backend correctness. The suite also relies on the selectors contract: form name attributes, required CSS classes, route paths, required button and link text, the debug interface, and the JWT storage behavior must match the shared expectations.

Next step

When the frontend passes its compatibility surface, use response envelopes and resource models to review parsing and rendering of every resource type.