4 ms·

No, this is nonsense. You don't write the test coverage up front! You think of a small chunk of functionality you are comfident about, write the tests for that

by twic 4y ago

No, this is nonsense. You don't write the test coverage up front! You think of a small chunk of functionality you are comfident about, write the tests for that (some people say just one test, i am happy with up to three or so), then write the implementation that makes those tests pass. Then you refactor. Then you pick off another chunk and 20 GOTO 10. If at some point it turns out your belief about the functionality was wrong, fine. Delete the tests for that bit, delete the code for it, make sure no other tests are broken, refactor, and 20 GOTO 10 again. The process of TDD is precisely about writing code when you don't know how the program is going to work upfront! On the other hand, implementing a well-defined spec is when TDD is much less useful, because you have a rigid structure to work to in both implementation and testing. I think the biggest problem with TDD is that completely mistaken ideas about it are so widespread that comments like this get upvoted to the top even on HN.

switchbak 4y ago
I feel like I'm in crazy town in this thread. Most of the replies seem to be misunderstanding the intent of TDD, and yours is one of the few that gets it right. Is general understanding of TDD really that far off the mark? I had no idea, and I've been doing this for essentially 2 decades now.
- pjmlp 4y ago
  No we really understand that the whole religion of only writing code after a failing test only applies to niche cases of libraries for headless applications in monoliths. Lets say my designer came to me and now wants bump mapped textures on engine, well I cannot touch that compute shader without writing a test first, so suggestions for a TDD framework for GPU shaders.
  - pydry 4y ago
    Ive done a form of TDD where I have a test scenario set up that generates a picture and I tweak the code until the picture looks right and then "freeze" it. Once frozen the test compares the picture (or other artefact) against the generated picture (or artefact). Im not sure if it'd be useful in your situation though.
    - pjmlp 4y ago
      Now apply that to a full native GUI application, while keeping in synch with UI/UX requirements and the rule of no code without failing tests.
      - pydry 4y ago
        Yeah, Ive kind of done this. The code changes that changed the UI - even changing some CSS - would cause a screenshot comparison failure on certain steps in the test. If it is what was expected then we overwrote the old screenshot with a new one. It isnt exactly the same as the TDD process coz sometimes you write the code first (e.g. CSS), eyeball it and then rebuild the screenshot if it looks correct. I'd say it's close enough though. I wont pretend it worked perfectly. The screenshot comparison algorithms were sometimes flaky and UIs can be surprisingly non-determinstic and you need to have a process to pull the database and update screenshots accordingly. However, it's the approach I'd prefer to take in the future (I havent done UIs for about 3 years now). I also wasnt religious about covering every single scenario with tests but I could have been. The company moved fast and sometimes they just wanted quick and not reliable.
        pjmlp 4y ago
        That is the whole deal, it was Web, so kind of easier than native, given its source based form, and even then, you had to bend the rules from TDD religion.
        switchbak 4y ago
        I think you're being a little uncharitable to the TDD folks here. Sure the early writing was very dogmatic, but real world TDD doesn't seem to be to be as rigid as you describe. Or perhaps you've worked with some real TDD zealots, that doesn't sound like fun. The folks I've worked with use these as guiding recommendations, not binding dictates. For some of the UI stuff you mentioned elsewhere, I've seen a stronger focus on testing not just business logic, but view logic as well (where possible), but generally not to the degree of testing the rendered output of the UI. Maybe that's a thing somewhere, but I haven't personally seen it.

by twic 4y ago

switchbak 4y ago

I feel like I'm in crazy town in this thread. Most of the replies seem to be misunderstanding the intent of TDD, and yours is one of the few that gets it right. Is general understanding of TDD really that far off the mark? I had no idea, and I've been doing this for essentially 2 decades now.

pjmlp 4y ago
No we really understand that the whole religion of only writing code after a failing test only applies to niche cases of libraries for headless applications in monoliths. Lets say my designer came to me and now wants bump mapped textures on engine, well I cannot touch that compute shader without writing a test first, so suggestions for a TDD framework for GPU shaders.
- pydry 4y ago
  Ive done a form of TDD where I have a test scenario set up that generates a picture and I tweak the code until the picture looks right and then "freeze" it. Once frozen the test compares the picture (or other artefact) against the generated picture (or artefact). Im not sure if it'd be useful in your situation though.
  - pjmlp 4y ago
    Now apply that to a full native GUI application, while keeping in synch with UI/UX requirements and the rule of no code without failing tests.
    - pydry 4y ago
      Yeah, Ive kind of done this. The code changes that changed the UI - even changing some CSS - would cause a screenshot comparison failure on certain steps in the test. If it is what was expected then we overwrote the old screenshot with a new one. It isnt exactly the same as the TDD process coz sometimes you write the code first (e.g. CSS), eyeball it and then rebuild the screenshot if it looks correct. I'd say it's close enough though. I wont pretend it worked perfectly. The screenshot comparison algorithms were sometimes flaky and UIs can be surprisingly non-determinstic and you need to have a process to pull the database and update screenshots accordingly. However, it's the approach I'd prefer to take in the future (I havent done UIs for about 3 years now). I also wasnt religious about covering every single scenario with tests but I could have been. The company moved fast and sometimes they just wanted quick and not reliable.
      - pjmlp 4y ago
        That is the whole deal, it was Web, so kind of easier than native, given its source based form, and even then, you had to bend the rules from TDD religion.
        switchbak 4y ago
        I think you're being a little uncharitable to the TDD folks here. Sure the early writing was very dogmatic, but real world TDD doesn't seem to be to be as rigid as you describe. Or perhaps you've worked with some real TDD zealots, that doesn't sound like fun. The folks I've worked with use these as guiding recommendations, not binding dictates. For some of the UI stuff you mentioned elsewhere, I've seen a stronger focus on testing not just business logic, but view logic as well (where possible), but generally not to the degree of testing the rendered output of the UI. Maybe that's a thing somewhere, but I haven't personally seen it.