Writing unit tests is futile exercise without a specification.
The software under test is always modeling something -- business logic, a communications protocol, a control algorithm, a standard, etc. Behind each of those things is a specification. If a specification doesn't exist then the software is called a prototype. For sustained long term incremental development a specification must exist.
The purpose of unit tests is to assert specification-defined invariants at the module interface level.
Unit tests are durable iff the specification they uphold is explicit and accessible to developers and the scope of the test is small. It's futile to write good tests for a module which has ambiguous utility.
priors: I worked in embedded SW and am now a PhD student.
This and the Meta post seem too crazy to be true... Feels uncomfortable that these are the daily lives of sine tech workers compared to my relatively 'relaxed' (but lower paying) tech job.
I found the linked article to be difficult to follow. Vacliv Smil wrote a book called Energy and Civilization (2017) in which he argues that the ability to harness energy is what makes civilizations thrive and enables the production of culture.
Start with the question: what is the problem that you want to solve? Next, find codebases that solve that problem and study how they do it.
Good design is so deeply tied to the domain details. Wonham's Internal Model Principle applies to code.
Example: I wanted to solve the problem of unit testing for embedded targets. I found open source projects that do this and read the code critically to see how and why it is written. As I build my own approach, I revisit theirs to learn more as my understanding of the domain deepens.
This is a wonderfully concise description of why software testing, especially GUI testing is cursed by dimensionality.
Type checking, borrow checking, invariants, hell even MISRA rules are all constraints imposed to reduce unmanaged state in programs. I like them for software reliability because they can help keep the complexity demon locked in the crystal.
The software under test is always modeling something -- business logic, a communications protocol, a control algorithm, a standard, etc. Behind each of those things is a specification. If a specification doesn't exist then the software is called a prototype. For sustained long term incremental development a specification must exist.
The purpose of unit tests is to assert specification-defined invariants at the module interface level.
Unit tests are durable iff the specification they uphold is explicit and accessible to developers and the scope of the test is small. It's futile to write good tests for a module which has ambiguous utility.
priors: I worked in embedded SW and am now a PhD student.