Continued from here.
There’s more to quality than just all the tests passing.
- The most interesting questions in software development are about trade-offs
- Does my software work? In the ideal world, you get immediate feedback.
- How frequently do you need feedback in the real world?
- Different kinds of feedback that we need:
- Is the software doing something useful?
- Is my codebase healthy?
- Have I broken anything?
- TDD can make you over-confident (example of ignoring QA altogether)
- Exploratory testing still valuable even for self-testing code
- Every test needs to fail at least once
Incremental small changes in design can cascade into major design improvements.
- Trade-offs: under-testing vs over-testing
- If you can’t change code confidently: under-tested
- If you spend more time changing tests than changing code: over-tested
- The intended audience of the software is part of the trade-off
- Is there a right ratio of code to tests? No, it depends.
- Delta coverage: is this test testing something unique?
- It’s OK to delete tests, especially if their delta coverage is zero
- Commenting out code to check if any tests fail (similar to mutation testing with cosmic-ray?)
- Only test things that can break
- Example: throw away implementation, keep tests, write new implementation under old tests
- Tests are the means to an end: user satisfaction
People cannot leave good ideas the fuck alone.
You either die a hero, or live long enough to become a villain.
- Development isn’t a science, we can’t repeat experiments
- … but a scientific mindset often helps.
- You have to over-use something to understand its proper use (learn the limit by exceeding it)
- TDD useful across various levels of developer experience
- Junior devs often make the mistake of not refactoring enough (just red and green)
- Senior devs should continue repeating the basics for the benefit of new people constantly coming through
- Approaching ideas from first principles helps avoid wandering off-track