Skip to content
End To End Tester

Every topic

All 83 articles on End To End Tester, by section and then A–Z.

Levels of Testing

What each level can prove, and what it costs

  • The Testing PyramidfoundationWhy cheap tests must outnumber expensive ones, what the pyramid actually claims, the trophy and honeycomb alternatives, and how to tell which shape you really have.
  • Unit TestingfoundationWhat a unit actually is, what belongs in a unit test and what does not, and the properties that separate a unit suite people run from one they skip.
  • Unit Testing with MockspracticalThe solitarist approach — isolate the unit behind test doubles. What it buys, the coupling it creates, and the three rules that keep a mock-heavy suite maintainable.
  • Unit Testing without MockspracticalThe sociable approach — real collaborators, state-based assertions, and tests that survive refactoring. What it buys, where it breaks down, and how to keep it fast.
  • Test DoublesfoundationDummy, stub, spy, mock and fake — Meszaros's five kinds of test double, what each is for, and why using the words precisely makes code reviews shorter.
  • Integration TestingfoundationTesting your code against real dependencies — databases, HTTP clients, message brokers — with Testcontainers, and what belongs at this level rather than above or below it.
  • Integration Testing with StubspracticalTesting against a dependency you control — WireMock, MSW and in-process servers — so error paths, timeouts and rate limits become testable instead of theoretical.
  • Contract TestingadvancedProving two services still agree without deploying both — consumer-driven contracts with Pact, provider verification in CI, and where contract testing beats end-to-end.
  • Component TestingpracticalTesting one deployable in isolation through its real interface, with its own dependencies containerised and everything beyond its boundary stubbed.
  • End-to-End TestingfoundationWhat belongs in an end-to-end suite and what does not, how many journeys are enough, and the practices that keep a browser suite from becoming the thing everyone ignores.

Practices & Patterns

The disciplines that decide whether a suite is trusted

  • Arrange-Act-AssertfoundationThe three-part shape every readable test has, why the act step should be one line, and the smells that show up when a test will not fit the pattern.
  • Given-When-ThenfoundationThe Gherkin vocabulary for describing behaviour, how it maps onto arrange-act-assert, and when a shared specification language is worth its cost.
  • Naming and Structuring TestsfoundationTest names that say what broke without opening the file, the naming conventions worth adopting, and how to organise a suite so people can find things.
  • Test-Driven DevelopmentpracticalRed-green-refactor, what TDD actually changes about a codebase, where it fits badly, and the honest evidence for and against it.
  • Behaviour-Driven DevelopmentpracticalBDD as a conversation practice rather than a tool choice — what the three amigos session produces, when Cucumber earns its place, and how it fails.
  • The Page Object ModelpracticalEncapsulating a screen behind a class so tests describe intent rather than selectors — what it fixes, the god-object failure mode, and modern alternatives.
  • The Screenplay PatternadvancedActors, abilities, tasks and questions — a compositional alternative to page objects for suites with many user types and deep flows.
  • Dependency Injection for TestabilityfoundationWhy injected dependencies are the one technique that makes isolated testing possible, the three forms of injection, and how to do it without a container.
  • Writing Testable CodefoundationThe properties that make code easy to test — pure cores, injected edges, no hidden state — and the specific smells that make it hard.
  • Test Data ManagementpracticalWhere a test's data comes from decides whether the suite can run in parallel, twice in a row, or at all — builders, factories, fixtures and per-test isolation.
  • Running Tests in ParallelpracticalHow parallelism turns hidden coupling into failures, the shared resources that clash, and how to make a suite genuinely safe to run concurrently.
  • Flaky TestspracticalWhy tests fail intermittently, the six root causes and how to fix each one, how to detect flakiness deliberately, and what to do with a test you cannot fix today.

Tools & Frameworks

Runners, drivers, mocking libraries and fakes

  • PlaywrightpracticalThe default browser automation tool in 2026 — auto-waiting locators, tracing, sharding and fixtures — with the configuration that matters and the mistakes that still cause flakiness.
  • Selenium WebDriverpracticalThe W3C standard for browser automation — where it still wins, the waiting model that decides whether a suite is stable, and Grid for scale.
  • CypresspracticalIn-browser test execution, automatic retry-ability and time-travel debugging — what Cypress's architecture buys, and the constraints that come with it.
  • JestpracticalThe default JavaScript test runner — configuration, projects, snapshot testing, fake timers, and the choices that keep a large Jest suite fast.
  • Jest MockingpracticalModule mocks, spies, manual mocks and timer control — how Jest's mocking works, and the patterns that keep it from taking over a suite.
  • VitestpracticalA Vite-native test runner with a Jest-compatible API — faster startup, native ESM and TypeScript, and the cases where it is the better default.
  • xUnit.netpracticalThe .NET runner with a fresh instance per test — Facts, Theories, fixtures, parallelism and the design opinions baked into it.
  • NUnitpracticalThe longest-serving .NET test framework — its constraint-based assertion model, attribute set, and the shared-instance behaviour you have to work with.
  • MSTestpracticalMicrosoft's own .NET test framework — where it sits against xUnit and NUnit, what MSTest 3 improved, and when it is the right organisational choice.
  • JUnit 5practicalThe Java standard — Jupiter's extension model, parameterised tests, nested classes, assertions with AssertJ, and running it all in CI.
  • pytestpracticalPython's test framework — plain assert, the fixture model that makes it different, parameterisation, and the plugins worth having.
  • RSpecpracticalRuby's specification-style framework — describe and context blocks, let and subject, matchers, and the readability trade it makes.
  • Mocking FrameworkspracticalMoq, NSubstitute, Mockito, unittest.mock, Sinon and the rest — what each ecosystem's mocking library does well, and the failure modes they share.
  • MoqpracticalThe .NET mocking library in practical detail — setups, argument matchers, verification, loose versus strict behaviour, and what to use instead where it strains.
  • TestcontainerspracticalRunning real databases, brokers and services as disposable containers from inside your test suite — the pattern that made integration testing cheap.
  • WireMockpracticalA programmable HTTP server for tests — stubbing responses, injecting failures, verifying requests, and recording real traffic to replay.
  • AppiumpracticalOne WebDriver-based API across iOS and Android — how the drivers map onto XCUITest and UIAutomator, locator strategies, and the cost of cross-platform tests.

UI Framework Testing

React, Angular, Vue, Knockout and the DOM underneath

  • DOM TestingfoundationTesting the layer every front-end framework produces — queries by role and accessible name, event simulation, jsdom's limits, and why selector choice decides maintainability.
  • Testing LibrarypracticalThe query API shared across React, Vue, Angular and Svelte — its guiding principle, the queries, user-event, and the mistakes it is designed to prevent.
  • Testing ReactpracticalComponents, hooks, context, server components and async state — what to test in a React application, what to leave alone, and how to avoid act warnings.
  • Testing AngularpracticalTestBed, the change detection model that confuses everyone, HttpTestingController, signals and standalone components — testing Angular without fighting it.
  • Testing Vue.jspracticalVue Test Utils and Testing Library, nextTick and reactivity timing, Pinia stores, composables and the mount-versus-shallowMount decision.
  • Testing Knockout.jspracticalKnockout view models are plain objects and observables are plain functions, which makes most of a Knockout application testable with no DOM at all.
  • Snapshot TestingpracticalRecording output and comparing it on every run — where snapshots earn their place, the approval reflex that destroys their value, and better alternatives.

Platforms

Browsers, desktop, mobile, Flutter, Avalonia, APIs

  • Browser TestingfoundationWhat a browser test can prove that nothing below it can, the three engines that matter, headless versus headed, and the cost model that should shape your suite.
  • Cross-Browser TestingpracticalWhich browsers actually need testing in 2026, what still differs between engines, and a strategy that catches real defects without tripling your pipeline.
  • API TestingfoundationTesting HTTP and message interfaces directly — the level most teams under-invest in relative to its value, and how it replaces most slow end-to-end tests.
  • Desktop Application TestingpracticalAutomating WPF, WinUI, WinForms, Electron and native desktop apps — the accessibility trees, the tooling, and why desktop UI automation is harder than the web.
  • Testing Avalonia ApplicationsadvancedAvalonia's headless test platform runs real UI tests in CI in milliseconds with no display server — the most testable desktop stack in .NET.
  • iOS App TestingpracticalXCTest, Swift Testing, XCUITest and the accessibility identifiers that make UI automation possible — plus what to run on a simulator and what needs a device.
  • Android App TestingpracticalJUnit and Robolectric for local tests, Espresso and Compose for instrumented UI, and the emulator strategy that keeps an Android suite affordable in CI.
  • Flutter TestingpracticalFlutter renders to a canvas with no native accessibility tree, so it brings its own three-layer test harness — unit, widget and integration — plus golden files.

Languages

TypeScript, C#, Java, Python — the same ideas, four dialects

  • Writing Tests in TypeScriptpracticalThe TypeScript testing toolchain — Jest or Vitest, typed doubles, async idioms, and the type-level tricks that make tests both safer and more readable.
  • Writing Tests in C#practicalThe .NET testing stack — xUnit, Moq or NSubstitute, WebApplicationFactory, Testcontainers — and the dependency injection story that makes it the most testable of the four.
  • Writing Tests in JavapracticalJUnit 5, Mockito, AssertJ and Testcontainers — the stack that has been stable for a decade, plus Spring's test slices and what they cost.
  • Writing Tests in Pythonpracticalpytest fixtures, the patching rules that catch everyone, async testing, and the toolchain for a Python project that has to hold up in CI.

Beyond Functional

Performance, data, security, access, accessibility

  • Performance TestingpracticalLatency, throughput and what breaks first — designing a performance test that answers a question, reading percentiles honestly, and putting a check in the pipeline.
  • Load, Stress and Soak TestingadvancedFinding where a system breaks rather than how fast it is — load profiles, the difference between the four kinds of test, and reading the results honestly.
  • Database TestingpracticalTesting migrations, constraints, queries and transactions — the layer everything else depends on, and the one most suites replace with a mock.
  • Security TestingpracticalWhat automated security testing can and cannot find, the scans worth having in every pipeline, and why business-logic flaws remain a human problem.
  • Authorization TestingpracticalThe highest-value security testing most teams are not doing — proving that the user who should not be able to do a thing genuinely cannot.
  • Accessibility TestingpracticalWhat axe and similar tools genuinely catch, the roughly two-thirds they cannot, and how accessible markup makes your test suite more maintainable at the same time.

Coverage

What the percentage means, and what it does not

  • Code CoveragefoundationWhat the percentage measures, why it is a finding tool rather than a target, how to collect it in each ecosystem, and how to gate on it without causing harm.
  • Coverage MetricspracticalLine, statement, branch, condition and path coverage — what each measures, why branch coverage is worth three times line coverage, and what none of them see.
  • End-to-End Code CoverageadvancedInstrument the application, run Playwright or Cypress against it, and merge the result with the unit run — the measurement that shows which code only your slowest tests protect.
  • Mutation TestingadvancedDeliberately break the production code and see whether the tests notice — the only practical measurement of whether a test suite actually asserts anything.

CI/CD Pipelines

Running all of it, on every push

  • Testing in GitHub ActionspracticalA complete pipeline — unit tests, integration with containers, sharded Playwright, coverage and artefacts — plus the caching and concurrency settings that make it fast.
  • Playwright ShardingpracticalSplitting a browser suite across machines and merging the reports back — the mechanics, the prerequisites, and how to choose a shard count that is actually faster.
  • Testing in Azure DevOps PipelinespracticalA full YAML pipeline with stages, jobs, parallel test slicing and the best built-in test reporting of any CI platform.
  • Testing in Bitbucket PipelinespracticalThe simplest CI model of the five — steps, caches, services and parallel groups — with the hard limits you need to design around.
  • Testing in TeamCitypracticalBuild chains, real-time test reporting and the best flaky-test detection of any CI platform — configured as Kotlin DSL rather than clicked together.
  • Testing in JenkinspracticalDeclarative pipelines, parallel stages, agent control and JUnit reporting — how to run a modern test suite on the CI server you probably inherited.
  • Terraform for Test InfrastructureadvancedProvisioning ephemeral test environments as code — per-branch stacks, workspaces, cost controls, and testing the Terraform itself.

Evidence & Diagnostics

Making a CI failure diagnosable

  • ScreenshotsfoundationCapturing the screen at the moment of failure, and using screenshot comparison as visual regression testing — configuration, masking and the flakiness to design out.
  • Screen RecordingspracticalVideo of a test run — when it is worth the storage, how to configure it so it costs nothing on green runs, and why a trace is usually better.
  • Traces and Debugging CI FailurespracticalA trace records every action, request, console message and DOM snapshot of a run — the single artefact that turns an unreproducible CI failure into a five-minute diagnosis.
  • Test ReportingpracticalGetting results out of the runner and in front of people — JUnit XML, pull request annotations, per-test history, and the numbers worth publishing.

Roles & Strategy

Who does what, and what to automate at all

  • SDET vs Automation Tester vs Manual QAfoundationThree genuinely different jobs that are routinely advertised as seniority levels of one — what each actually does, and what goes wrong when the distinction is lost.
  • Test StrategypracticalDeciding what to test, at which level, and what not to test at all — written down, so it is a choice rather than an accident.
  • Shift Left TestingfoundationMoving quality work earlier — into design, the pull request and the developer's inner loop — and the version of the idea that is just moving work without moving support.
  • Quality OwnershipfoundationWhen a defect reaches production, whose failure is it? The answers that feel good, the one that works, and the practices that make it real.

A–Z