About End To End Tester
A reference for test automation, written for people who already write software and now have to decide what to test, at which level, with which tool, and how to keep it running on every push without it becoming the thing everyone ignores.
How it is organised
83 articles across 11 sections. The sections are the axes along which testing decisions actually get made:
- Levels of Testing — What each level can prove, and what it costs
- Practices & Patterns — The disciplines that decide whether a suite is trusted
- Tools & Frameworks — Runners, drivers, mocking libraries and fakes
- UI Framework Testing — React, Angular, Vue, Knockout and the DOM underneath
- Platforms — Browsers, desktop, mobile, Flutter, Avalonia, APIs
- Languages — TypeScript, C#, Java, Python — the same ideas, four dialects
- Beyond Functional — Performance, data, security, access, accessibility
- Coverage — What the percentage means, and what it does not
- CI/CD Pipelines — Running all of it, on every push
- Evidence & Diagnostics — Making a CI failure diagnosable
- Roles & Strategy — Who does what, and what to automate at all
Every article declares what it relates to, and the site computes the reverse: if unit testing points at test doubles, test doubles shows unit testing back. That is the whole navigation model. There is no search box because a search box is what you build when your links are not good enough.
What it is not
It is not a tutorial series and it is not vendor documentation. Where a tool's own docs are the right answer, the article says so and links to them rather than paraphrasing them badly. What you get here instead is the part the docs do not cover: when to reach for the thing, what it costs, and what it looks like when it goes wrong at scale.
Samples are in TypeScript, C#, Java and Python. Not every article carries all four — where a concept is genuinely language-neutral it gets one sample in whichever language shows it most plainly, and where the differences matter it gets all of them.
How the site is built
Next.js on the App Router, server-rendered, with every article prerendered at build time from markdown. There is no client-side routing of content and no JavaScript needed to read a page.
Underneath it is CQRS and event sourcing — the Adam Dymitruk and Martin Dilger flavour of event modelling — sharing its architecture with the other applications in this family. A reference site does not need an event log to count thumbs-up, and that is rather the point: the site is also the worked example that the articles about testing evented systems draw on. Commands append, queries replay, and a background processor handles everything that touches the outside world.
Tools are next. For now the writing is the product.
Corrections
Every page has a “was this useful” control, and a note left with a thumbs-down is the most useful thing the site receives. There is also a feedback page for anything longer.