Q40 of 40 · Core Java
How do you decide between staying with Java for automation vs migrating to Kotlin or TypeScript?
Core JavaLeadjavakotlintypescriptlanguage-decisionautomation-strategyleadership
Short answer
Short answer: The decision turns on four axes: team skill, ecosystem fit, AUT stack, and maintenance horizon. Java is the right default when the team is already proficient, the AUT is Java/JVM-based, and you have a large existing suite. Kotlin is worth considering when your team is already writing Kotlin for the product and you want null-safety and DSL ergonomics without rewriting the JVM toolchain. TypeScript makes sense when the AUT is a web SPA, the dev team is JS-native, or you're consolidating around Playwright/Cypress.
Detail
Decision framework
1. What does the team already know and what will they maintain?
Java test code written by a TypeScript developer becomes unmaintained quickly.
2. What is the application under test?
JVM app with internal API hooks → Java/Kotlin has classpath access devs
won't give to TS tooling.
Web SPA → TS/Playwright has native browser tooling and dev alignment.
3. How large is the existing suite?
>500 tests in Java → migration cost is high; incremental hybridisation safer.
Greenfield → choose freely based on axes 1 & 2.
4. What is the hiring/growth plan?
Building a team of full-stack devs who write tests → TS aligns.
Dedicated SDET team from Java background → Java/Kotlin.
Java — keep when:
- Large existing JVM automation suite (Selenium, REST Assured, TestNG/JUnit 5)
- Deep JVM profiling/performance test tooling (JMH, async-profiler)
- API/backend tests that need classpath access to internal libraries
- Team fluency is high; Java 17–21 is modern enough (records, sealed classes, virtual threads)
Kotlin — migrate/start when:
- Team already writes Kotlin (Android, Spring Boot)
- You want coroutines for async test flows without Java's verbosity
- Interop with Java libraries is needed (100% JVM interop)
- DSL readability matters for BDD-style test descriptions
// Kotlin test DSL ergonomics vs Java equivalent
// Backtick function names give readable test names
fun `login with expired token returns 401`() {
val resp = apiClient.login(expiredToken)
assertThat(resp.statusCode).isEqualTo(401)
assertThat(resp.body?.errorCode).isEqualTo("TOKEN_EXPIRED")
}
TypeScript — migrate/start when:
- AUT is a web app and you want Playwright or Cypress with first-class TS support
- Dev team owns test code and they are TypeScript-native
- Contract testing (Pact) and mock servers fit the JS ecosystem
- You want to eliminate a language boundary between dev and QA contributions
Hybrid / incremental path (often the right call)
Phase 1: Run Java and TS suites side-by-side, shared CI pipeline.
New UI tests → Playwright/TS.
Existing API/perf tests → stay Java.
Phase 2: Measure maintenance cost per test by language over 6 months.
Phase 3: Decide based on data — migrate only if Phase 2 shows clear
maintenance advantage for the investment.
What to avoid
- Big-bang migration: rewrites take 6–12 months, test coverage craters during transition
- Language chosen by individual preference rather than team consensus — divergent skills create bus-factor risk
- Migrating mid-release-cycle to hit a deadline — migration is a platform investment, not a sprint story
// WHAT INTERVIEWERS LOOK FOR
A structured decision framework, not a language preference. Consideration of team skills, AUT stack, existing suite size, and hiring plan. Pragmatism around hybrid approaches — most real teams don't do big-bang rewrites. Strong answers acknowledge that the 'right' answer is org-specific and show how to gather the data to decide.
// COMMON PITFALL
Advocating for a language based on personal enthusiasm without mapping it to the team's constraints. A lead who says 'TypeScript is just better' without asking about team skills or existing test investment is making a decision that could fail in execution.