5 ms·

What kind of "good engineer" refuses to write tests?

BigJono 8y ago
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.
- 2trill2spill 8y ago
  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.
  - BigJono 8y ago
    ? CRUD apps generally go into production, unless something goes horribly wrong.
  - TeMPOraL 8y ago
    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.
- spricket 8y ago
  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 :)
spricket 8y ago
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
- luord 8y ago
  > 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.
  - spricket 8y ago
    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 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.

2trill2spill 8y ago
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.
- BigJono 8y ago
  ? CRUD apps generally go into production, unless something goes horribly wrong.
- TeMPOraL 8y ago
  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.
spricket 8y ago
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 :)

spricket 8y ago

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

luord 8y ago
> 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.
- spricket 8y ago
  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.