> you don’t just get a build failure telling you that you want 610 instead of a blank string
So I had to scratch my head a bit because I was thinking: "Wait, the whole point is that you don't know whether what you're testing is correct or not, so how can you rely on that as input to your tests!?".
But even though I didn't understand everything they do yet I do see at least a big case where it makes lots of sense. And it happens to be a case where a lot of people see the benefits of test: before refactoring.
> What does fibonacci(15) equal? If you already know, terrific—but what are you meant to do if you don’t?
Yeah a common one is reuse a function in the same language which you believe is correct (you probably haven't proven it to be correct). Another typical one is you reuse a similar function from another language (once again, it's probably not been proven it is correct). But if two implementation differ, you know you have an issue.
> let d = create_marketdata_processor () in > ( Do some preprocessing to define the symbol with id=1 as "APPL" )
Typo. It's AAPL, not APPL. It's correctly used as AAPL later on.
FWIW writing tests better become a joyful experience for we're going to need a lot* of these with all our AI generated code.
it's also very nice if you have a test-last working style, that is, develop the code first using some sort of ad hoc testing method, then when you're convinced it's working you add tests both as a final check that the output is what you expect across a lot of different corner cases, and to prevent regressions as you continue development.
Is it really to escape from "getting bogged down in the specifics" and being able to "focus on the higher-level, abstract work", to quote OP's words? I thought naively that engineering always has been about dealing with the specifics and the joy of problem solving. My guess is that the drive is toward power. Which is rather natural, if you think about it.
Science and the academic world
I have always failed to understand the obsessive dream of many engineers to become managers. It seems not to be merely about an increase in revenue.
Is it to escape from "getting bogged down in the specifics" and being able to "focus on the higher-level, abstract work", to quote OP's words? I thought naively that engineering has always been about dealing with the specifics and the joy of problem-solving. My guess is that the drive is towards power, which is rather natural, if you think about it.
Science and the academic world suffer a comparable plague.