Why engineers don't test code

Compilation is the only unit test I need.

YDD is a thing, and it's a good thing. Sometimes, you have to get things done fast and messy and embrace the chaos. It is also a common thing. For all the talk of TDD, test pyramids, and test metrics, good testing just isn't that common.

But it should be. Testing is a good thing. It stops you shipping mistakes. So why do engineers use every excuse under the sun not to do it? Let's debunk the greatest hits of testing avoidance.

I don't have time

Yes, you do. And if you genuinely don't, that's a red flag.

If your deadlines don't account for proper testing, they're setting you up for failure. This isn't just about you-it's about the entire development process and how it's managed. If you're constantly scrambling without time to test, you're overcommitted. This needs to be addressed to give you time to produce good code.

If testing is overly time-consuming, you might need better tools and processes. Investing in test automation can save enormous amounts of time in the long run.

It's not my job

If you write code, testing is absolutely part of your job—full stop. If you don't know how to test effectively, that's a training issue. Your organization should invest in your skills. If testing isn't valued across the board, that's a leadership issue. Quality needs to be everyone's responsibility.

Separating development from testing creates silos that lead to bugs and inefficiencies. By embracing testing as part of your role, you're not just improving code quality but becoming a more well-rounded and valuable engineer.

Tests take too long to run

Then fix them. Slow tests are a technical problem, not an excuse to skip testing altogether.

If your tests are slow, it's likely because they've been neglected. There are three common reasons here:

Infrastructure problems: Slow tests might indicate a need for better hardware or more efficient test environments.
Poor test design: Tests that take too long are often poorly optimized. This is an opportunity to improve your testing skills and processes.
Lack of prioritization: Not all tests need to run all the time. Implementing proper test categorization and CI/CD pipelines can help manage test runtime.

The code is too simple to need tests

Even simple code can have bugs, and simple code has a way of becoming complex over time.

Part of the reason it becomes complex over time is that it doesn't have tests. Tests aren't just about catching bugs but also about defining behavior, facilitating refactoring, and providing confidence in changes. With tests, you can constrain your code to the tested functionality.

Tests act as a form of documentation, clearly defining what a function or module should do. This clarity helps prevent scope creep within functions, as any additions that break existing tests are immediately flagged. Testing encourages better function design and more modular code by forcing you to think about inputs, outputs, and edge cases upfront.

Over time, this leads to a more maintainable and extensible codebase, as each piece of functionality is well-defined and constrained by its tests. In essence, good tests don't just verify your code—they shape its architecture.

It's not done here

Yes, it's not. But that doesn't have to be so. If testing isn't part of your definition of "done," your definition needs work.

This excuse often reveals a deeper cultural issue within the organization:

Lack of testing culture: If testing isn't considered part of the development process, that's a flaw. It indicates a lack of commitment to quality at a systemic level.
Incomplete development lifecycle: A mature software development process includes testing as an integral part. If your org doesn't, it's time to evolve.
Resistance to change: "We've always done it this way" is a dangerous mindset in tech. If your org is resistant to adopting better practices, that's a red flag.

As a developer, you have the power and responsibility to advocate for better practices.

Tests are boring

Yes, they are. We're not going to lie. Writing tests isn't as much fun as building new features or optimizing existing ones.

The answer here is to not write them-get AI to do it. AI can do the heavy lifting of finding elements, reasoning about assertions, and generating tests. With AI-powered testing, you can focus on defining the desired behavior and let the AI handle the details of test case generation. This saves time and often results in more comprehensive test coverage than manual efforts.

Automating your testing process makes it less tedious and ensures consistency and reliability. By leveraging AI for test automation, you can create a robust testing framework that runs continuously, catching regressions as soon as they occur. AI-powered testing tools can identify patterns and potential issues that human testers might overlook, providing valuable insights that go beyond simple pass/fail results.

AI can also adapt to changes in the UI without flaking, and suggest fixes to the code. This adaptability means less time spent updating brittle tests and more time actually improving your code.

I am perfect

Yes, you are. And perfect people write tests.

What you get in return for being perfect

If you have to test your code, it's because you've built something good that users want to work. After all, if there are bugs in an app no one uses, are they really bugs?

This is why we built Momentic. We believe two things:

Tests are good
Engineers hate tests

Thus we should have tests without the engineers writing them. If this sounds like something you want, then check out Momentic to continue not testing your code.