My workplace uses an old proprietary language and framework that feels decades behind modern standards. The testing tools we have are really painful to work with and most of our codebase is a tangled mess that makes writing meaningful tests nearly impossible. Only the basic utility functions can be tested properly.
For years our team has been asking to modernize the framework and clean up the core modules so we can actually write decent tests. But these improvement requests always get delayed because shipping new features takes priority.
Now management wants better test coverage and they’re requiring every new feature to include detailed unit test plans. Each test needs its own Jira ticket and documentation in Confluence pages.
This feels like being told to work harder instead of working smarter. We’ve been asking for better tools to do our jobs effectively but keep getting ignored. Then they expect us to somehow produce quality tests with the broken setup we have.
Am I being unreasonable for wanting to resist this new policy? It seems backwards to mandate extensive testing while refusing to fix the underlying problems that make testing so difficult.
Your pushback is totally justified, but document everything instead of just resisting. When I dealt with similar bureaucratic BS at my last job, I tracked metrics like crazy. Every test that failed because of framework limits, every hour wasted fighting broken tools, every bug that got through because the legacy system made proper testing impossible - I logged it all. The trick was framing this data as risk assessment, not complaints. Management suddenly gave a damn when they saw their mandate was creating technical debt faster than preventing bugs. Maybe propose a compromise - implement basic smoke tests for new features while building a case for gradual modernization. You won’t look obstructionist, just someone balancing immediate needs with long-term code quality.
Management pushing mandatory testing without fixing the core problems? Yeah, that’s classic. But you’re absolutely right to push back - it makes zero technical sense. I’ve been there with a mainframe system where every single test took 20 minutes just to compile and run. Here’s what worked for me: I stopped arguing against the policy and started pitching small pilot projects instead. Instead of asking them to modernize everything, I picked one tiny module we could refactor as proof of concept. We modernized just that piece, wrote real tests for it, and showed them the productivity difference. The contrast was so obvious that management finally got why their mandate was backfiring. Sometimes you’ve got to show them a working alternative instead of explaining why their approach sucks.
I totally get your frustration! It’s like asking us to run a marathon in flip flops. Without the right tools, you can’t expect quality work. Showing them the time difference with modern tools might help, but who knows if they’ll actually fix anything.
sounds like they want to look good without spending money on good tools. classic mgmt BS. try malicious compliance - give them exactly what they want. write detailed tests that break constantly bc their tools suck. sometimes letting them feel the pain works better than fighting about it.
You’re absolutely right to push back on this. I went through the exact same thing three years ago with a legacy .NET 1.1 system. Management wanted 80% coverage but wouldn’t fix the underlying architecture mess. Here’s the thing - forcing unit tests on badly designed legacy code just creates fragile tests that break every time you make a tiny change. You get false confidence and waste tons of dev time. What saved us was tracking the actual hours we spent fighting with crappy testing tools versus what we’d need with proper tooling. We showed management hard numbers proving that refactoring critical components first would cut long-term testing costs by about 60%. They finally let us do a phased refactor when they saw the current approach was bleeding money.
Been there way too many times. The manual documentation thing - creating Jira tickets and Confluence pages for every single test - it’s just busywork that doesn’t make the code any better.
Here’s what actually worked: I built automation bridges between the old system and modern testing. Instead of trying to fix their ancient framework, I pulled data out, ran tests externally, then fed results back into their reporting system.
The trick was showing management they’d get their precious metrics without all the manual garbage. Once they saw automated test coverage reports and integration with their ticketing system, they completely flipped from “write more docs” to “how fast can we roll this out everywhere.”
You can build these workflows pretty easily without touching their legacy mess. Extract data, process it with decent tools, push results back. Management gets numbers, devs get to use tools that don’t suck.
Latenode makes this integration really simple - you can connect old systems to new processes without writing tons of custom code.