I don't write many tests. I've found with experience and heavy linting you can avoid the vast majority of bugs. Not much point to spending a ton of time on tests if they hardly ever break for nontrivial reasons. My normal setup for java is:

Linters: ErrorProne Checkstyle PMD SpotBugs Nullaway

All with highly customized settings

All warnings enabled on javac

Google-java-format to autoformat everything on build.

For runtime analysis: LeakCanary to find memory leaks

Hibernate with interceptors to find long queries

Rest framework or gRPC with interceptors for long calls

Proxied JDBC connector to find long or N+1 queries

Opentracing/Zipkin integration to make debugging crazy stuff easier

NewRelic for projects where the $ makes sense

And I'm always on the lookout for more of these tools. In the long-run they save enormous amounts of time by preventing buggy code and keeping most shitty hacks out of the codebase.

Unlike tests, they don't break constantly and add more maintenance burden to the codebase. And it's less work, one time setup vs ~50% codebase bloat to add tests.

I see project leads call for more tests all the time to "fix" an unreliable codebase where there's zero linting. It won't save you from everything but I swear it's like 95% bug reduction. You should have most/all of these tools in place before you consider writing the first tests

> I've found with experience and heavy linting you can avoid the vast majority of bugs.

No, you can't.

In fact, I can't even begin to see how "apply this specific standard to the code" (linting) is even remotely related to "know everything about this particular domain so you don't make any mistakes in creating an application for it" or "know everything about this particular system so that a given difference in configuration screws up your application at run time".

You seem to be primarily a java developer so I understand why you prefer avoiding tests (among the many things that Java makes absurdly difficult, writing tests is one of them) but you should still write tests .

Look at any serious open source project, most of them have hundreds, thousands of tests. It's almost presumptuous to think that one knows more than the community.

> I swear it's like 95% bug reduction.

The only situation where linting really causes that much of an impact, that I've seen, is in an application where a huge portion of the code was just connecting or boilerplate that should've been brought from third party libraries anyway, and was written only because of the NIH syndrome.

Mind you, having code style is necessary so that any given developer can quickly get up to speed and more easily review other developer's code, but it doesn't (nor it shouldn't) tell you whether whatever you wrote actually works.

Assuming otherwise is like pretending that a movie featuring state of the art special effects, cinematography, etc, isn't still Transformers or similar garbage.

Linting is about so much more than code style and standards. Since we use auto format I have almost all the style checks off. What it does catch is hundreds of different types of potential bugs. Uninitialized variable. Missing null check. Deprecated or beta marked api used. Improper thread synchronization and double locking. Reassignment of parameters. Conditional check that's always true/false. This list is huge, and in my experience it catches mistakes constantly.

For the average crud app, if you're wrong about the requirements the tests will be wrong anyways. It sounds like you're talking more about TDD which IMO is a cargo cult. And I'm hardly the only one with that opinion. Integration tests are important but that's more about running data through the code all at once than testing each function in isolation.

Also, many open source projects get along with hardly any tests. The Linux kernel is probably the best example, but there's tons of popular projects without good or any tests. Check NPM popular repositories, I'll bet you more than half of the top 500 are under 10% code coverage. Tons of huge apps are doing fine without tests, and many I've worked on with tests are still horrible.

I haven't really noticed any contribution from having lots of tests. IMO what's far more important is linting and maintaining code standards. It's hard to write a function that's horrible to debug when the linter limits you to 300 lines. Or a class that's totally incomprehensibly long when the linter limits you to 1000. All of my debugging nightmare projects have been due to lack of sound OOP principles, huge files of spaghetti. Good linting prevents that from happening.

Besides Java my other big language is TypeScript. Using Mockito in java isn't that bad, and JUnit5 or TestNg are decent. Certainly easier than getting tests working in the garbage fire that is Angular6 + Jasmine + Karma.

I don't see how linting and experience prevents logic errors, missed corner cases, or misunderstandings of the requirements. In my experience integration tests are crucial to robust software.

It does nothing for missed requirements, but in my experience the test will be wrong if the requirements are anyways. I don't disagree with integration tests, which are usually just running the software through the motions in a semi automated way. I just think unit tests are pretty useless with good linting.

You might be surprised how much bad logic static analyzers can catch though.

I don't see how unit testing prevents that stuff either. How do you write a unit test for a corner case if you've missed it? If you're aware of it's existence, why not just update the code to handle it?

Quickcheck like libraries are reasonably good at finding missing corner cases in my code. It also helps if the person writing the test is different from the person writing the code and the person writing the requirement.

That's true. Regression tests are also useful.

But TDD is about neither, it's about test-first approach at the unit test level, which is arguably less useful and leads to design by random walk.

I know a couple that would tell me to go jump if I suggested they aim for 90% code coverage on a CRUD app. They also write very clean, maintainable code and do it very, very quickly.

There's always a trade off.

I'm one of those. Unit tests are a waste of time IMO. It usually takes almost as much code to test logic as it does to write it, so I always wondered why the TDD folks don't just implement the code twice and check the result at the end :)

I'm not writing a CRUD app, I'm writing a program that my company expects to put into production. Writing tests is very much a part of writing production code.

If you're in webdev, CRUD apps is probably 95+% of what gets put into production. CRUD isn't meant as pejorative here, it's just most of the things people do with software fits in the model of Create/Read/Update/Delete access to a DB.

?

CRUD apps generally go into production, unless something goes horribly wrong.