| > 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. |