Languages

The concepts in test automation are the same everywhere. The idioms are not, and a test that reads naturally in one language often reads like a translation in another.

These four pages exist because the most common practical question in test automation is not "what is a stub" but "what does this look like in the language I actually have to write it in". Each covers the default toolchain, the assertion style people actually use, how doubles are made, how async is handled, and how the suite is run in CI.

• TypeScript — Jest or Vitest for units, Playwright for browsers, and a type system that makes doubles either delightful or infuriating depending on how the code was written.
• C# — xUnit by convention, Moq or NSubstitute for doubles, and the best-integrated dependency injection story of the four, which shows up directly in how easy the tests are.
• Java — JUnit 5, Mockito, AssertJ, and Testcontainers, which was born in this ecosystem and changed how integration testing is done everywhere else.
• Python — pytest, whose fixture model is genuinely different from everything else here and worth understanding even if you write no Python.

#Which to write your end-to-end tests in

Usually: the same language as the application. Not because the tooling is better, but because tests written in a language the team does not use daily get maintained by whoever drew the short straw, and that is how a suite rots. The exception is a polyglot estate with a dedicated automation team, where one language across all suites beats four half-learned ones.

If you are choosing fresh and have no constraint, TypeScript with Playwright is the shortest path from nothing to a maintainable browser suite in 2026.