u/martinig

Earlier this year, Uber’s Java monorepo used JUnit 4 as the primary framework for its test suite. While functional, reliance on this framework prevented us from adopting the enhanced testing capabilities of JUnit 5, which launched over eight years ago. Moreover, active development on JUnit 4 ceased in 2021, meaning bugs, security patches, and features would no longer get addressed. There was a clear case for transitioning to a modernized test framework, but it came with challenges. With over 600,000 JUnit 4 tests spanning 15 million lines of code, we faced both a technical and cultural challenge: motivating developers to adopt JUnit 5. A manual migration would require developers to learn the Jupiter API and migrate custom test suites, consuming valuable engineering hours. Additionally, Uber uses Bazel™, which lacks native JUnit 5 support. Future JUnit versions plan to drop JUnit 4 support entirely, making migration increasingly urgent. Given these challenges, we needed a large-scale migration approach that’d automate the transition while minimally disrupting workflows.

An article about software management metrics with a zest of humor. Excerpt: "Learning how to manage is a long race - it takes many years and each lap offers new learnings. Along the way, anchors emerge that can help orient a manager when a number of other variables are in flux. Below we offer a number of these anchors. They are based on philosophy, experience, and analysis; we hope they’ll be of some use."

Metrics exist to answer two questions: how good is the software we deliver, and is our testing approach actually working? AI-generated tests broke the old answers to both. QA metrics were never really about numbers. They exist to answer two questions. First, how good is the software we are delivering to customers? Second, is our testing approach actually working, or are we just going through the motions?

Everyone talks about the importance of building trust in teams. Companies spend significant time and budgets for various workshops, training, trips, and exercises. After all, you must invest in trust-building and team bonding to achieve high-performance in the workplace, right? Well, no. There’s a much better way.

We usually assume that trust should be slowly built over time and the transition from regime and micromanagement to growing freedom is slow. I suggest you reverse the order.

James Bach writes about who is responsible for software quality. Excerpt: "In opposition to my idea that software testing should be a role, and not just a task, I am sometimes told that True Agile does not permit this. Why? Because, in Agile, “quality is everyone’s responsibility.” This statement is sometimes issued as if it were a moral truism that is beyond argument. Or sometimes as a moral achievement that is unique to Agilists, as if it had never occurred to earlier generations of software developers to help each other build nice things. Either way, it doesn’t make sense to me. The first response that comes to my mind is “I’m talking about testing, not quality. Why are you dragging quality into this?” Testers do not assure quality. Testers CANNOT assure quality. Testers do not now and never have “owned quality” in any way."

But even if we set that aside, quality should not be considered “everyone’s responsibility.”