Why Most Unit Testing Is Waste [pdf]

The cause was that one of the VIPER classes forced unwrapped an optional reference to its view. Force unwrapping is without the if, just assume it’s always valid and crash if it’s not.

The problem was they made this assumption because the view is never nil except for one uncommon edge case, if a network operation completed after the view was disposed. So the fix was easy, remove the force unwrap (you should never force unwrap in Swift, it’s terribly bad).

But what about our other VIPER views? It took me a couple minutes to review all 20, and Trey all had the same identical flaw. Fixing them took seconds, but individually testing the fixes took a few hours.

Should I have left those other 20 views alone so our app could mysteriously crash for some of our hundreds of thousands of users?

A more recent bug I found on my own was a memory leak caused by our main views network closures holding strong references to the ViewController. This caused code to fail that was still in old dead copies. So I fixed the closures and we no longer have old copies of the VC handing around forever. I didn’t have time to do a search at that moment, but I took notes in my dev log so I can review every view controller (50 or 60) for similar problems. Why wouldn’t I? How many known bugs and random unduplicated problems would go away if we got our Viewcontrollers memory Managemnt right? im betting at least a few, and that I’ll eliminate some future problems before they can even be found.

Software engineering is usually 80% fixing bugs. Developing rigorous standards to prevent their formation can give you much more time to build new and improved features.

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

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.