4 ms·

Slightly off-topic but I thought it might be interesting: you can easily modify tests to adapt to your changing architecture as well. Personally I use TDD to h

Slightly off-topic but I thought it might be interesting: you can easily modify tests to adapt to your changing architecture as well. Personally I use TDD to have an easy entry point to run through my code, so the first instance of a test for an api might only check status code It makes the process very iterative, as you can continuously run through your code just by saving

BiteCode_dev 5y ago
Let's say you test an api, since yoy are taling about status code. You have to test all kind of cases with wrong inputs, various user states and so on. You can of course write the test to simulate all that, but's way harder than just using your user UI which lets you discover it and put a breakpoint in the endpoint to inspect. I may not remember where to get the header data in this framework, or maybe the client send me a weird queryset param and I must figure out why, or I my validation is failing in some case and I must check it out. I can't simulate something I don't know about or don't understand yet. Plus using the UI will make you realize you forgot to limit input length or what happen if the user doesn't have any phone number or if it's tuesday. The minimal use case you will write your code against will likely be only good in theory in your mind unless you do something very basic. You will probably throw it away in the end in exhange for IRL code learned by feed back, and you'll have written all that for nothing. This is were TDD proponents say ypu shoud write the minimal case and see all that stuff incrementally, but again, it's way easier and faster to just fiddle with the UI and write the code I need then test each case that imagine each case incrementally, and find the proper incatation to make the whole thing works. I'm exagerating for the sake of the argument, but that's the result I get every time I work on a project where the team requires TDD. Incidently, those are the projects with the worst UI as well, because dev don't use it enough.
- 411111111111111 5y ago
  your whole argument is a straw-man. i don't think that anyone would disagree that you can get caught up in writing too many tests too early, consequently loosing sight out of your objective and ending up with a bad implementation. My point was that just writing super easy and happy-path tests at the start is a valid strategy for TDD as well, and does not cause any of your imaginary issues.
  - BiteCode_dev 5y ago
    Aggressive tone and a throw away account, this is the end of the thread for me.
    - 411111111111111 5y ago
      Rereading my comment does indeed sound very aggressive. It wasn't intentional and I'm sorry for that. I have to work on that.
pjc50 5y ago
> you can easily modify tests to adapt to your changing architecture as well. Can you? Surely it depends; most systems end up with more LOC in the tests than the tested code, and the tests multiply the cost of refactoring. I've had success with the "happy path first" kind of TDD, where you write a use case and implement to that and only then come back and fill in other tests.
- 411111111111111 5y ago
  I might've been too unclear in my comment. I was indeed speaking specifically about the issue the parent comment had with writing detailed tests before the application logic is implemented, just to be forced to change them because the initial idea for the api had to be changed. Changing existing apis comes with a very different set of challenges

BiteCode_dev 5y ago

Let's say you test an api, since yoy are taling about status code. You have to test all kind of cases with wrong inputs, various user states and so on. You can of course write the test to simulate all that, but's way harder than just using your user UI which lets you discover it and put a breakpoint in the endpoint to inspect. I may not remember where to get the header data in this framework, or maybe the client send me a weird queryset param and I must figure out why, or I my validation is failing in some case and I must check it out. I can't simulate something I don't know about or don't understand yet. Plus using the UI will make you realize you forgot to limit input length or what happen if the user doesn't have any phone number or if it's tuesday. The minimal use case you will write your code against will likely be only good in theory in your mind unless you do something very basic. You will probably throw it away in the end in exhange for IRL code learned by feed back, and you'll have written all that for nothing. This is were TDD proponents say ypu shoud write the minimal case and see all that stuff incrementally, but again, it's way easier and faster to just fiddle with the UI and write the code I need then test each case that imagine each case incrementally, and find the proper incatation to make the whole thing works. I'm exagerating for the sake of the argument, but that's the result I get every time I work on a project where the team requires TDD. Incidently, those are the projects with the worst UI as well, because dev don't use it enough.

411111111111111 5y ago
your whole argument is a straw-man. i don't think that anyone would disagree that you can get caught up in writing too many tests too early, consequently loosing sight out of your objective and ending up with a bad implementation. My point was that just writing super easy and happy-path tests at the start is a valid strategy for TDD as well, and does not cause any of your imaginary issues.
- BiteCode_dev 5y ago
  Aggressive tone and a throw away account, this is the end of the thread for me.
  - 411111111111111 5y ago
    Rereading my comment does indeed sound very aggressive. It wasn't intentional and I'm sorry for that. I have to work on that.

pjc50 5y ago

> you can easily modify tests to adapt to your changing architecture as well. Can you? Surely it depends; most systems end up with more LOC in the tests than the tested code, and the tests multiply the cost of refactoring. I've had success with the "happy path first" kind of TDD, where you write a use case and implement to that and only then come back and fill in other tests.

411111111111111 5y ago
I might've been too unclear in my comment. I was indeed speaking specifically about the issue the parent comment had with writing detailed tests before the application logic is implemented, just to be forced to change them because the initial idea for the api had to be changed. Changing existing apis comes with a very different set of challenges