[pqwEfkvjs]

Yes, but devs who don't write unit tests are probably not going to write integration or acceptance tests either.

Maybe except of a one guy who I talked to a while ago. He does not write unit tests, because static type checking in C++ takes care of everything that unit tests do (according to him), but I actually have seen his code that contained few system tests, so there are exceptions.

[wtetzner]

Except that the featured article isn't saying not to worry about testing at all, it's about how to actually get value out of your testing.

[pqwEfkvjs]

I think it advocates wrong attitude towards software development and I think most points made in the article are just plain wrong and stupid.

I guess the main reason for my condescending sentiment is due that the author gives 0 examples of code that requires tests vs code that does not so it is actually not.

[Const-me]

> devs who don't write unit tests are probably not going to write integration or acceptance tests either

Why do you think they aren’t? I don’t write unit tests except when I’m specifically paid extra for that (yes, coding strongly-typed languages too), but I do write other kinds of tests as I see fit.

[pqwEfkvjs]

Doing TDD is a habit and if a developer does not find unit tests useful or practical, then I don't think they are going to write tests that are more complicated than unit tests.

Btw, what type of software do you write and how do you know if it actually works?

[Const-me]

> I don't think they are going to write tests that are more complicated than unit tests

I find unit tests are useless for most cases. But this doesn’t stop me from writing more complicated tests. Even unit tests when they’re useful. E.g. for sufficiently complex low-level SIMD math routines: inputs & outputs are simple, no IO, no multithreading, no large dependencies, no side effects, just some computations, and tons of weird _mm256_verb_typesuffix intrinsics everywhere i.e. it’s very easy to make mistakes writing these.

> what type of software do you write

Lately Windows CAD and Linux embedded. Previously mobile software, PC and console videogames, CNC & robotics, GIS, WinCE/embedded, multimedia/video codecs, utilities for Windows administration, lots of other stuff.

> how do you know if it actually works?

I use strongly typed languages that catch 99% of stupid errors at compile time. I test it manually while using debugger at the same time to inspect internal state. I design my software to be testable, e.g. logging, asserts, configurable debug dumps, well-defined interfaces between components so they can be tested in isolation, etc.

P.S. Today I’ve fixed 3 bugs in my code.

[Windows] A user tried using my software on old AMD CPU, it didn’t work ‘coz SSE 4.1 instruction set is not supported.

[Windows] Under some conditions, my code reads value from a depth+stencil D3D texture while the GPU is still rendering previously submitted commands into the same texture, read fails.

[Linux] When both HDMI and DSI displays are connected, my DRM/KMS client code selects the wrong one.

All three are caused by environment or external hardware, and you can’t unit test these.