> Within this process, every individual act of building is a process in which space gets differentiated. It is not a process of addition, in which preformed parts are combined to create a whole, but a process of unfolding, like the evolution of an embryo, in which the whole precedes the parts, and actually gives birth to them, by splitting.
Reading that run a thread through my brain connecting some observations:
- That TDD video from PragProg where the first implementation of a production class was developed in the same file as its test class, being extracted to its own file only after it was "ripe" enough.
Seems to be the same principle, but applied to different scales. Now I really need to read The Timeless Way of Building!
Like really! I just ran across this again and re-read it. And most of what it says is pretty much mostly what I've been thinking for some years. "Good advice!" is what I keep thinking.
I'm glad you wrote this. It is invaluable. Even if you missed the irony of my post that you were reacting to.
Great post! The redundant test dilemma is one I grapple with a lot.
One way I sometimes resolve it is to ask myself how confident I am that I've discovered the "right" organization into sub-elements, or whether the boundaries are likely to shift. I'll keep the system-level tests around to the extent that I care about the freedom to inline and re-extract sub-elements later.
How would this change if system-level tests aren't slow to run? Is there a threshold where the conclusions here will take over, but below which the calculus is different? eg, if TimeToRun(S) is 2x TTR(C)? 5x? 10x or more?
There are 8 potential outcomes of C1, S1, S2 passing or failing. Some of these are impossible, if C1 or S2 failing means S1 fails too. But S1 can still fail even if C1 and S2 pass.
> Within this process, every individual act of building is a process in which space gets differentiated. It is not a process of addition, in which preformed parts are combined to create a whole, but a process of unfolding, like the evolution of an embryo, in which the whole precedes the parts, and actually gives birth to them, by splitting.
Reading that run a thread through my brain connecting some observations:
- "grow like a tree" https://youtu.be/Saaz6D1azlU?si=UU2aNXnVjoCqNplP&t=2851
- https://tidyfirst.substack.com/p/ad-hoc-infrastructure
- That TDD video from PragProg where the first implementation of a production class was developed in the same file as its test class, being extracted to its own file only after it was "ripe" enough.
Seems to be the same principle, but applied to different scales. Now I really need to read The Timeless Way of Building!
Bingo!
Fyi, link to https://testdesiderata.com/ doesn't work for me. maybe the www is tripping it up?
Should be fixed. Now waiting for DNS propagation (he says, sounding misleadingly informed).
Also not a link on the web. Also, now a cert/name mismatch error :(
Apparently we all need to wait up to 24 hours for magical stuff to happen.
Yes on that last point. ;->
And this is a good article, nonetheless.
Like really! I just ran across this again and re-read it. And most of what it says is pretty much mostly what I've been thinking for some years. "Good advice!" is what I keep thinking.
I'm glad you wrote this. It is invaluable. Even if you missed the irony of my post that you were reacting to.
It's interesting to notice why we decided to extract sub-elements: what was the motivation? Some examples:
- We wanted to re-use that logic somewhere new.
- We saw duplication and wanted to merge it.
- We notice a code smell and want to address it.
- The caller becomes more readable this is extracted.
- We learn that this concept is part of the domain, and want to express that in code.
- We want to improve or introduce a test for something.
More abstractly, either to increase cohesion or reduce coupling. The benefits of which are as you describe.
Great post! The redundant test dilemma is one I grapple with a lot.
One way I sometimes resolve it is to ask myself how confident I am that I've discovered the "right" organization into sub-elements, or whether the boundaries are likely to shift. I'll keep the system-level tests around to the extent that I care about the freedom to inline and re-extract sub-elements later.
How would this change if system-level tests aren't slow to run? Is there a threshold where the conclusions here will take over, but below which the calculus is different? eg, if TimeToRun(S) is 2x TTR(C)? 5x? 10x or more?
That's an important part of the tradeoff.
Wonderful, this is an argument I have with myself all the time.
I would disagree that S1 is redundant.
There are 8 potential outcomes of C1, S1, S2 passing or failing. Some of these are impossible, if C1 or S2 failing means S1 fails too. But S1 can still fail even if C1 and S2 pass.