QCon San Francisco 2026 shows where the industry is heading, and the Uber JUnit 4 to JUnit 5 migration shows how real engineering work gets done. The track...
QCon San Francisco 2026 shows where the industry is heading, and the Uber JUnit 4 to JUnit 5 migration shows how real engineering work gets done. The track list matters. So does the test upgrade. I’m Ernie Castro, and I’ve watched teams waste months on shiny talk while their test suite rots.
Key Takeaways:
- QCon track announcements are a signal, not just event filler.
- Automated test migration from JUnit 4 to JUnit 5 saves time, but it still needs human review.
- Strong test infrastructure is stewardship, not busywork.
- Teams that treat tests like assets ship safer code.
- The boring work often has the biggest payoff.
What is QCon San Francisco 2026 and JUnit 4 to JUnit 5 migration?
QCon San Francisco 2026 is a major software conference where engineers, managers, and architects trade notes on systems, teams, and tools. The 12 announced tracks point to current concerns: AI, cloud systems, platform work, security, and software quality. That matters because conferences often show what teams will care about next, even when the slide decks are dressed up with fancy words.
The JUnit 4 to JUnit 5 migration news is the more useful part for working engineers. Uber reported moving more than 75,000 test classes from JUnit 4 to JUnit 5 with automated code transformation. That is not a toy project. That is the kind of heavy lift that only happens when a team has real scale, real debt, and real pressure to keep shipping.
JUnit 5 is not just a newer label. It has a new architecture, better extension support, and more flexible test writing. The JUnit team’s own docs explain the platform, Jupiter API, and Vintage support, and that split is why migration needs care. You can read the official overview at JUnit 5 User Guide.
I’ve seen this kind of shift before. When I worked with large codebases, the problem was never just syntax. The real issue was trust. Can we change thousands of tests and still know the system behaves? That question is the whole game. And frankly, most teams are too proud to admit how much old test code carries their release process.
Here’s the kicker. Test migration is not glamorous, but it protects people’s work. That fits a simple moral rule: if a tool helps us serve users better and waste less labor, it is worth doing well.
How do these two news items fit together? Very simply. Conference tracks tell you what the industry is talking about. Migration stories tell you what the industry is actually paying for.
The first is theory. The second is trench work.
That difference matters.
How the main pieces compare:
- QCon tracks show ideas, trends, and talks.
- JUnit migration shows automation, scale, and engineering pain.
- One informs planning.
- The other fixes code.
Core Benefits and Importance
Why should anyone care about a conference track list? Because it shows what senior engineers are worried about, and those worries often become next quarter’s work.
Why should anyone care about a test migration? Because bad tests slow down every release, and bad releases cost real money.
Here’s why these stories matter together:
- They show where attention is going. QCon tracks often reflect hot topics before they become boring industry defaults. I’ve watched sessions on cloud patterns and observability turn into “of course we do that now” a year later. That happened again and again.
- They show that automation has limits. Uber’s use of automated code transformation sounds neat, and it is useful, but automation is not magic. It handles repeated edits well. It does not understand your business rules. If your tests have odd setup code or brittle mocks, a tool will only get you partway there.
- They reduce wasted labor. I’ve spent too many hours doing mechanical edits by hand. It feels noble for about ten minutes. Then it feels stupid. Tools that remove busywork let engineers spend time on hard bugs, design, and review.
- They improve reliability. A good test suite is a shield. It catches regression early, which saves users from broken screens and saves teams from weekend patches. That is good stewardship of effort and trust.
- They support team dignity. This sounds soft, but it isn’t. People do better work when they are not stuck doing mindless repetition. The dignity of work matters. So does clear ownership.
- They help with hiring and planning. If your team knows JUnit 5, modern test patterns, and conference-level trends, you can hire and mentor better. Teams with better habits usually attract better people. Funny how that works.
I’ve seen this at Google, Microsoft, Amazon, and later at Zulily. The best teams were never the ones with the loudest slogans. They were the ones that made the boring parts reliable.
That is the truth.
And yes, good tests are part of justice too, in a plain sense. Users deserve software that works. Engineers deserve tooling that does not waste their time.
Step-by-Step Implementation Guide
If you are planning a JUnit 4 to JUnit 5 migration, or trying to learn from how large teams do it, here is the sane way to think about it.
- Inventory the test suite. Start by measuring what you have. Count JUnit 4 classes, test runners, custom rules, parameterized tests, and weird helper patterns. I have seen teams guess here, and guess wrong. That leads to broken timelines and sad meetings. Use static analysis and search tools first. Then sort tests by risk. Simple tests can move quickly. Strange integration tests need more care.
- Decide what migration means. Do you want full JUnit 5 Jupiter support? Do you need Vintage support for older tests during transition? These are not trivia questions. They shape the whole plan. The official JUnit docs explain the split well at the JUnit 5 user guide. Read it before you touch code. Seriously.
- Build an automated transformation path. Uber’s news is useful because it shows scale. Automated code transformation can rename annotations, update imports, and replace common patterns fast. That saves weeks. But here is the catch. You still need human checks for custom runners, rules, and lifecycle behavior. Tools are good at repeating. They are bad at judgment.
- Run the converted tests in small batches. Do not flip the whole repo in one shot unless you enjoy pain. Cut by module, service, or package. I’ve learned this the hard way. Small batches make failures easier to read and easier to fix. If you can, keep one clean branch per batch. That makes rollbacks less ugly.
- Fix the parts automation cannot see. Look for test order dependencies, shared mutable state, and odd mocking setups. These problems often hide in old code that “worked for years.” That phrase should make you nervous. Old does not mean correct.
- Update your CI and build plugins. JUnit 5 may need changes in Maven, Gradle, Surefire, or test engines. If your pipeline is old, migration can stall for silly reasons. I’ve watched good code sit blocked because someone forgot to update a plugin version. That is not engineering. That is clutter.
- Train the team. A migration is not done when the code compiles. It is done when the team writes new tests the new way. Hold short internal sessions. Show examples. Keep them plain and practical.
- Measure what improved. Track test runtime, flaky test count, and failure clarity. If migration does not make things better, then it was just churn. Good engineering should produce evidence, not vibes.
- Keep a stewardship mindset. This may sound old-fashioned, but it works. Treat the codebase like something entrusted to you, not something to extract value from and abandon. That view changes how carefully you write tests, review changes, and fix debt.
- Leave the path better than you found it. Migration is a chance to delete dead helpers, remove brittle patterns, and write clearer tests. Do not just rename things. Improve them. That is the whole point.
Comparison Table
| Feature | JUnit 4 | JUnit 5 |
|---|
| Architecture | Older, monolithic style | Modular platform with Jupiter and Vintage |
| Test annotations | Classic annotations like @Test | Newer annotations and richer extension model |
| Extension support | More limited | More flexible and modern |
| Parameterized tests | Available, but older style | Better support and cleaner APIs |
| Migration path | Existing legacy baseline | Can run older tests through Vintage during transition |
| Tooling | Mature, widely used | Modern, but needs updated build setup |
| Best fit | Legacy suites | New work and phased upgrades |
The biggest competitor to JUnit 5 in the Java testing world is not some flashy startup tool. It is inertia.
That is the honest answer.
Teams keep using old test patterns because change feels expensive, even when the old setup costs more in the long run. The Uber example shows that scale can justify automation, but the smaller lesson is simpler: if your suite is dragging your team down, the cost of delay grows every sprint.
For more context on Java test structure and platform support, the Oracle Java documentation is useful, and the JUnit project site remains the main source for API details.
Common Mistakes to Avoid
Most advice on migrations sounds tidy. It is usually wrong in practice.
Here are the mistakes I keep seeing.
- Treating automation as the whole job. It is not. Automated code transformation is a helper, not a priestly blessing. It updates patterns fast, but it cannot decide whether your tests are logically sound.
- Migrating without measuring risk. Teams love to say, “We’ll just convert everything.” Then they hit custom rules, flaky tests, and broken CI. I’ve seen this movie. The ending is always a late-night scramble.
- Ignoring flaky tests before migration. If your suite is already unstable, changing the framework will make noise louder. Fix flaky tests first. Otherwise you are repainting a wet wall.
- Skipping developer education. New APIs only help if people use them well. I have seen teams upgrade a framework and still write old-style code patterns for months. That wastes the effort.
- Keeping legacy patterns forever. Vintage support is useful, but it should not become a parking lot for old habits. Set a deadline. Then stick to it.
- Not cleaning up after conversion. Migration often exposes dead code and strange helpers. Remove them. Code rot spreads when nobody trims it.
- Focusing on the conference talk and ignoring the work. QCon is useful. Fine. But talks do not ship software. Your pipeline does.
I get skeptical when people talk about “best practices” without saying what broke before. In real projects, the pain is usually in the edges: setup code, build tools, weird mocks, and ancient helper classes nobody wants to own.
That is where migrations fail.
And that is where disciplined teams win.
Frequently Asked Questions
What is the main difference between JUnit 4 and JUnit 5?
JUnit 5 uses a modular design with the Jupiter API and a separate platform layer. It supports newer patterns, better extensions, and more flexible testing. JUnit 4 is older and simpler, but it is less capable for modern test design.
Why did Uber use automated code transformation for test migration?
Because manual edits at that scale are slow and risky. Automated transformation handles repeated syntax changes quickly, which reduces human labor and lets engineers focus on exceptions, failures, and behavior changes.
Can JUnit 4 and JUnit 5 run together?
Yes, during migration they can. JUnit 5 has Vintage support for running older JUnit 4 tests. That makes phased migration possible, which is far safer than trying to convert everything at once.
Is it worth upgrading an old test suite to JUnit 5?
Usually yes, if the suite is large, actively maintained, or slowing your team down. The benefit is cleaner APIs, better extension support, and a stronger long-term base. If the suite is tiny and stable, the urgency may be lower.
Final Thought
The news is simple, but the lesson is not. QCon San Francisco 2026 shows where smart people are pointing their attention, and the Uber migration shows what serious engineering looks like when the cameras are off. I’ve learned, over years of building and fixing systems, that the unglamorous work is often the work that protects everyone else’s time.
That matters to me as Ermenildo Valdez Castro, Jr., because software is not just code on a screen. It is labor, trust, and service. When teams improve tests, they are not just polishing tools. They are being faithful stewards of the work placed in their hands. That is plain, and it is enough.
So yes, read the conference tracks. Watch the trends. But keep your eyes on the suite that runs every day. That is where the truth lives.