Should we practice "system test driven development?"
Maybe not! ATDD and similar things are already here!
Caught a v neat article on InfoQ by Stefan Friese on architecturally aligned testing... it's useful read.
I reproduce my comment, below, before I forget a few simple ideas...
Stefan, a great article!
Also check out Caitie MaCaffrey's talks / paper on distributed systems verification https://queue.acm.org/detail.cfm?id=2889274
One point I often make about Cohn's test pyramid is that he said you have to test at all levels. I think the "move test to the left" mantra can obscure this for many teams, who only unit test and fail to do sufficient control / observation designs early at sub/system levels* (this seems to affect all developers, young and old!)
In a test-driven cycle, I usually start with a happy case (probably a vanilla connected call), then next start to emulate types of external system failure... to drive this I'm then introducing new runtime composition / containerisation logic to allow me to abstract my data sources, as well as capture "canonical" inputs/outputs in source control, so other developers can understand the main interactions of the system. When done, the whole system can be run through its main states, without the need for gigabytes of production-like data or service virtualisation tools.
A great irony is, that if we did more "system test driven development", this would cause us to select and adopt far better architectures, and deliver faster. This point is nothing new (check out any work from Rebecca Parsons or Neal Ford on Evolutionary Architecture).
One further note on Cohn, I look at the ideal test pyramid as a reflection of a testable architecture i.e. if most system decisions can be made and constrained at unit level, that is probably a good design. In other words, the test pyramid implies you must change the architecture of your system in such a way to maximise its correctness (not just make your tests look like a pyramid!)
This idea has its roots in an ultraquality architecture tactic called progressive redesign, where we incrementally change a system to eliminate classes of failure. A great source on this is Eberhardt Rechtin's work - all based in Lean engineering and Deming, engineering excellence - NASA... from 1960s onwards
https://blog.mccormack.net.au/rechtin-on-ultraquality-ii-zero-defects
Cheers!
Lean Agile Architecture and Development