When faced with a failing test, you make it pass as simply as possible, and then you summon all your computer science / programming experience to refactor the code into something more elegant and maintainable.
Why bother making it pass “as simply as possible” instead of summoning all that experience to write something that don’t know is stupid?
TDD doesn’t promise to drive the final implementation at the unit level
What exactly does it drive, then? Apart from writing more test code than application code, with attendant burdens when refactoring or making other changes.
The rhythm of TDD is to first write a failing test. That starts driving the design of your production code. To do that you need to invoke a function/method with arguments that responds with an expected answer.
At that point you’ve started naming things, designing the interface of the unit being tested, and you’ve provided at least one example.
Let’s say you need a method like isEven(int number): Boolean. I’d start with asserting 2 is even in my first test case.
To pass that, I can jump to number % 2 == 0. Or, I can just return true. Either way gets me to a passing test, but I prefer the latter because it enables me to write another failing test.
Now I am forced to write a test for odd input, so I assert 3 is not even. This test fails, because it currently just returns true. Now I must implement a solution that handles even and odd inputs correctly; I know modulus is the answer, so I use it now. Now both tests pass.
Then I think about other interesting cases: 0, negative ints, integer max/min, etc. I write tests for each of them, the modulus operator holds up. Great. Any refactoring to do? Nope. It’s a one-liner.
The whole process for this function would only add a few minutes of development, since the implementation is trivial. The test runtime should take milliseconds or less, and now there is documentation for the next developer that comes along. They can see what I considered (and what I didn’t), and how to use it.
Tests should make changing your system easier and safer, if they don’t it is typically a sign things are being tested at the wrong level. That’s outside the scope of this lemmy interaction.
Either way gets me to a passing test, but I prefer the latter because it enables me to write another failing test.
But you could just write that failing test up front. TDD encourages you to pretend to know less than you do (you know that testing evenness requires more than one test, and you know the implementation requires more than some if-statements), but no-one has ever made a convincing argument to me that you get anything out of this pretence.
Tests should make changing your system easier and safer, if they don’t it is typically a sign things are being tested at the wrong level
TDD is about writing (a lot of) unit tests, which are at a low-level. Because they are a low-level design-tool, they test the low-level design. Any non-trivial change affects the low-level design of a component, because changes tend to affect code at a certain level and most of those below it to some degree.
Why bother making it pass “as simply as possible” instead of summoning all that experience to write something that don’t know is stupid?
What exactly does it drive, then? Apart from writing more test code than application code, with attendant burdens when refactoring or making other changes.
The rhythm of TDD is to first write a failing test. That starts driving the design of your production code. To do that you need to invoke a function/method with arguments that responds with an expected answer.
At that point you’ve started naming things, designing the interface of the unit being tested, and you’ve provided at least one example.
Let’s say you need a method like
isEven(int number): Boolean. I’d start with asserting 2 is even in my first test case.To pass that, I can jump to
number % 2 == 0. Or, I can just returntrue. Either way gets me to a passing test, but I prefer the latter because it enables me to write another failing test.Now I am forced to write a test for odd input, so I assert 3 is not even. This test fails, because it currently just returns
true. Now I must implement a solution that handles even and odd inputs correctly; I know modulus is the answer, so I use it now. Now both tests pass.Then I think about other interesting cases: 0, negative ints, integer max/min, etc. I write tests for each of them, the modulus operator holds up. Great. Any refactoring to do? Nope. It’s a one-liner.
The whole process for this function would only add a few minutes of development, since the implementation is trivial. The test runtime should take milliseconds or less, and now there is documentation for the next developer that comes along. They can see what I considered (and what I didn’t), and how to use it.
Tests should make changing your system easier and safer, if they don’t it is typically a sign things are being tested at the wrong level. That’s outside the scope of this lemmy interaction.
But you could just write that failing test up front. TDD encourages you to pretend to know less than you do (you know that testing evenness requires more than one test, and you know the implementation requires more than some if-statements), but no-one has ever made a convincing argument to me that you get anything out of this pretence.
TDD is about writing (a lot of) unit tests, which are at a low-level. Because they are a low-level design-tool, they test the low-level design. Any non-trivial change affects the low-level design of a component, because changes tend to affect code at a certain level and most of those below it to some degree.