4 ms·

I don't do the TDD like a waterfall. I don't do upfront all the tests, there is a discussion between the code (what express the business need) and the tests tha

I don't do the TDD like a waterfall. I don't do upfront all the tests, there is a discussion between the code (what express the business need) and the tests that "wraps" it inside a safe zone (what ensures that the behavior is the one intended). As such, as the idea grow, both the code and the test grow at the same time. Look at [0] to have an idea of how the tests extend the safe zone along the code. Also, I much prefer a lot of nice unit tests over a lot selenium tests (which takes a lot of time to run). [0]https://github.com/charlesthk/python-resize-image/commits/master?after=e4a7e5a8f69ebf491ef069c13530d159594e2c87+69 https://github.com/charlesthk/python-resize-image/commits/ma...

taeric 9y ago
Rereading my post, I see where it sounds more strawman of the "entire wall of tests." I did not mean it to be the final test suite is written first. Instead, I intended that to be the wall that you will be passing in a given cycle. So, for a small development cycle, you add in some new tests that will be this cycle's "wall" of failing tests that you flip to passing. And don't take this to be an indication that I think integration tests are somehow superior. They all have advantages and there is a massive cost benefit tradeoff that has to be considered at all times. It is easy to talk in strawmen. Such that I can confidently say if you have a set of tests that always fails together, that should just be a single test. However, I do not feel that statements like that are informative, precisely because it is a judgement call masquerading as a rule.
- jaggederest 9y ago
  > So, for a small development cycle, you add in some new tests that will be this cycle's "wall" of failing tests that you flip to passing. That's not right either. There is no "wall". Writing tests helps you write the code which helps you write better tests. It's mutual recursion, not a one-way waterfall.
- tieTYT 9y ago
  That's not how you're supposed to do it. Write one test, get it to pass, repeat.
  - taeric 9y ago
    Right. In that, you still write all of the tests before the code. If you are objecting only to the rhetoric of "wall" of tests. That just depends on your size of units. Think of it more as hurdles of tests. :)
    - tieTYT 9y ago
      > write all of the tests before the code Everyone is interpreting this as, "write 10 tests then try to get them all to pass at once". That is not how you TDD. You write one, then get it to pass, then write another. Maybe you mean, "write the test before the code", but when you say "write all tests before the code", it's not interpreted the same way.

taeric 9y ago

Rereading my post, I see where it sounds more strawman of the "entire wall of tests." I did not mean it to be the final test suite is written first. Instead, I intended that to be the wall that you will be passing in a given cycle. So, for a small development cycle, you add in some new tests that will be this cycle's "wall" of failing tests that you flip to passing. And don't take this to be an indication that I think integration tests are somehow superior. They all have advantages and there is a massive cost benefit tradeoff that has to be considered at all times. It is easy to talk in strawmen. Such that I can confidently say if you have a set of tests that always fails together, that should just be a single test. However, I do not feel that statements like that are informative, precisely because it is a judgement call masquerading as a rule.

jaggederest 9y ago
> So, for a small development cycle, you add in some new tests that will be this cycle's "wall" of failing tests that you flip to passing. That's not right either. There is no "wall". Writing tests helps you write the code which helps you write better tests. It's mutual recursion, not a one-way waterfall.
tieTYT 9y ago
That's not how you're supposed to do it. Write one test, get it to pass, repeat.
- taeric 9y ago
  Right. In that, you still write all of the tests before the code. If you are objecting only to the rhetoric of "wall" of tests. That just depends on your size of units. Think of it more as hurdles of tests. :)
  - tieTYT 9y ago
    > write all of the tests before the code Everyone is interpreting this as, "write 10 tests then try to get them all to pass at once". That is not how you TDD. You write one, then get it to pass, then write another. Maybe you mean, "write the test before the code", but when you say "write all tests before the code", it's not interpreted the same way.