| title | tags |
|---|---|
Five underplayed TDD Premises |
TDD |
https://www.geepawhill.org/2018/01/18/five-underplayed-premises-of-tdd-2/
We make more money by shipping more value faster. And TDD is the best thing we found so far to do that.
:::info TDD = Ship More Value Faster :::
TDD is NOT about
good citizenship(you're not immoral if you don't TDD)quality: it's not about raising the quality of the code, even if it may raise the quality of code (but we don't do TDD for the quality of the produced code)art/craft: TDD is not about excellence
The reason for doing TDD is that we go faster. We put more value into the field faster than if we didn't do TDD.
TDD is not an algorithm for coding ("if you follow these rules you'll get TDD"): everyday, all the time, we have to rely on individual human judgment to take the right decisions when following the TDD rules.
If you're doing TDD, you're going to be required to make active judgments, every day, constantly, to guide you through the process.
They have a direct relationship: they go up together and they go down together.
External quality is anything users of a system could tell you about that system, what they see:
- is it slow? is it fast?
- is it complete? or some features are missing?
- is it stable?
- is it pretty?
- is it responsive?
Internal quality is things you can tell only by studying the code:
- is it readable? scannable?
- is it easy to change?
- is it well factored?
- is it broken into chunk that we can change independently of each other?
- is it well tested?
:::success You can trade external quality for productivity ::: In other words:
- less speed, completeness, or beauty means more time to work on other things
- you can produce more on valuable things and delay other functional or not-functional requirements
But... :::danger You can't trade internal quality for productivity ::: because internal quality doesn't work like external quality
The way to test a chain is by testing each individual link of that chain.
Sounds like the "integrated tests are a scam" topic by JBrains.
Chain Tests: we write tests that concentrate on the individual connection in the dependency chain.
Chain Tests are the cheapest tests
There are lots of actors that are constantly balancing when we build the software:
- the market
- the tech capabilities of the platform we use
- the capabilities of the devs
- the price
- the performance
- the capabilities of those interpreting the market
- ...
Tests and testability become first class factors in steering our design.
We use tests and testability as one of the factor we keep considering all the way through the development, asking:
- is it testable?
- is the test cheap?
- can we make it cheaper?
These five premises are UNDERPLAYED because people that are accustomed to TDD don't think at these premises, they learned them and so they don't pay attention at explaining those premises. We give them as granted.
So pay attention to the technicalities of TDD, but don't forget to teach (and learn) these 5 premises!
Cose che mi sono piaciute:
-
il fatto che puoi negoziare la qualità esterna con la produttività (e.g. per ora non faccio questa funzionalità, o non ottimizzo questo aspetto, ma così posso concentrarmi sulle cose più importanti), mentre NON puoi fare la stessa cosa con la qualità interna
-
il fatto che il TDD non è una tanto questione di "moralità" come a volte si dice (vedi zio bob) ma una questione soprattutto opportunistica, perché serve per andare più veloci e costruire su basi più solide, quindi è - come diverse pratiche usate nei metodi agili - una tecnica per la gestione e la riduzione del rischio
Cose che mi hanno convinto meno:
- alcune premises per me sono un po' "mischiate" (e.g. Correlation, su che tipo di test scrivere, non so quanto sia allo stesso livello di importanza delle altre)
- alcune un po' fumose (e.g. Steer).
Bello secondo me che racconti di cose che spesso sono date per scontate dai TDDers navigati, con il rischio di non trasmetterle a chi si avvicina al TDD e magari si concentra troppo sui tecnicismi della tecnica senza considerare questi aspetti "sistemici"