|
|
|
|
|
|
by squeaky-clean
3076 days ago
|
|
|
> Exactly. We have the code file, but not any documentation separate from the code, such as notes, plans, attempts, reasoning, etc. I agree with you that it can be tested. But it doesn't explain anything about why it works, or what methods the author tried that didn't work as well. If you ever had to make it faster, or make it work better on different hardware, you'd be starting from scratch again. |
|
|
Optimizations like these a great area for tests because the test files can keep all the various implementations and can benchmark them as you like.
This enables the tests to prove that the a new implementation is indeed optimal over all previous implementations, and continues to be optimal even when there are changes in external dependencies such as hardware, libraries, etc.
> But it doesn't explain anything about why it works
IMHO it does, for all the areas expressed in the original link and the parent comment.
Here are the original link examples:
1. "What [TDD] doesn’t do is get you to separate the code’s goals from its implementation details."
IMHO first write the code's goals as tests, then write the method implementations. The tests may need new kinds of instrumentation, benchmarking, test doubles, etc.
2. "[D]oes the description of what Module 3 does need to be written in terms of the description of what Module 1 does? The answer is: it depends."
IMHO write modules with separation of concerns, and with clear APIs that use API tests. If you want to integrate modules, then write integration tests.
3. "Quick! What does this line of code accomplish? return x >= 65;"
IMHO write code more akin to this pseudocode: