4 ms·

>no wonder we end up with such buggy junk software... people... write tests! absolutely condescending and holier than thou. I view TDD as a premature optimizat

>no wonder we end up with such buggy junk software... people... write tests! absolutely condescending and holier than thou. I view TDD as a premature optimization when writing software that isn't simplistic or cut-and-dry CRUD. Trying to do something new doesn't always mean there's a known output before writing the actual code. Experimentation is a valid thing in software development and writing tests before writing the code would stifle some types of development. In a lot of cases it's bass-ackwards to write tests before the implementation is producing a useful result. I know this type of development might seem foreign to some, but you don't always know what you don't know before you start experimenting while writing code, and TDD doesn't really fit all types of development.

latchkey 4y ago
> absolutely condescending and holier than thou. That was an update after I was downvoted. You're right, there are reasons to not always do TDD. Writing a tool to inspect websockets, isn't one of them.
- kristiandupont 4y ago
  >Writing a tool to inspect websockets, isn't one of them. What kind of developer makes a blanket statement like that? There are all kinds of situations where debugging is more like detective work. When you discover the problem, then you have the knowledge necessaryto actually write the test that fails and which you can then make succeed.
  - latchkey 4y ago
    > What kind of developer makes a blanket statement like that? One with over 20 years of experience building software used by millions of people daily. You're trying to generalize a very specific conversation. OP was talking about building a tool to debug websockets. You don't need to debug websockets, you need to debug your code that is sending and receiving data _over_ websockets. In that case, you don't even need websockets at all. Meaning you don't need a tool to inspect the data either. Just make sure that your code is sending and receiving the correct data and you're done. Of course, if you want to build a tool, go ahead... that's your choice, but my question is still valid. Why not write tests?
    - ShroudedNight 4y ago
      If people don't have the same positive relationship with tests that you do, I could easily see "writing tests" generate enough negative sentiment to seriously degrade a person's capacity engage the near whimsical part of the brain that allows one to think laterally at non-trivial 'distance' from the obvious problem. It could easily be as simple as writing tools is more inspiring / engaging to the OP than writing tests.
      - latchkey 4y ago
        You're 100% right and that's a large part of the problem here.
      - jasonm23 3y ago
        I'll chime in here because it looks like you've had a terrible time with someone who's a [insert word of choice]. TDD "evangelism" is often toxic and abusive. The actual practice of a functioning TEAM (not just the devs) who know what it is and how it works, changes things fundamentally for the better. Spikes are used to do the "whimsical" how the F do we do Y, parts. XP devs don't TDD those and the code is usually tossed out (with the good bits used to help build the production code.) Similarly TDD isn't a religion, and only an fool would apply it like one. The good parts are, you get a test suite, you get developer examples of how to use a unit, you get an extra step to think about naming, so you're _slightly_ less likely to be saddled with a poorly thought out API / naming scheme. It's broadly useful, helps teams integrate code, much faster. Everyone needs to be playing the game, though, and they need to know the rules. C2 wiki is about the best place to find organic conversations about XP and TDD (archived though, so no sanctimonious claptrap from the likes of me), and the wide internet is a great place to get polarized. I'm sorry you got a bad taste, and it may have put you off, but a functioning TDD team is about the sanest, quickest, dev team you'll have the pleasure of working with. While, as you've found, an oppressive diktat to DO TDD PROPERLY when the team isn't really doing that, is hellish.
- leptons 4y ago
  >Writing a tool to inspect websockets, isn't one of them. That's assuming quite a bit and not at all true in all cases. I deal with websockets with wireless IoT devices and I can tell you that your insistence that debugging websockets doesn't require writing any custom tools is just wrong. So great, you wrote a test that passes. Your test runs it once. Maybe your test runs it twice. But what happens when the IoT device fails in an unexpected way after the 150th run? Your test isn't going to catch that. If you ran tests repetitively then your test is never going to finish in a reasonable amount of time. Do you think running the tests for an entire day is reasonable? No. That's why sometimes building a "debugging CLI" like OP wrote is needed. Not everything can always be debugged with a simple test, or any kind of test. Network congestion effects can be tricky to work out. Memory leaks in remote devices you don't control. There's a whole lot of reasons why tests aren't always the catch-all some people think they are. I'm not saying don't write tests, just don't go around suggesting they're a cure-all.
  - latchkey 4y ago
    It isn't easy, but all of this can (and should) be tested. It will produce far better and more reliable code. You can certainly run tests 151 times. In fact, if you think you're going to find a bug after that many runs, a test suite is perfect for automating the execution. Don't believe me? Jespen is a great example of difficult distributed testing done well: https://jepsen.io/ https://jepsen.io/
    - leptons 4y ago
      You sound like you have TDD Stockholm Syndrome and can't fathom any other kind of software development.
      - latchkey 4y ago
        I wouldn't describe TDD as captive or abusive.
        leptons 4y ago

latchkey 4y ago

> absolutely condescending and holier than thou. That was an update after I was downvoted. You're right, there are reasons to not always do TDD. Writing a tool to inspect websockets, isn't one of them.

kristiandupont 4y ago
>Writing a tool to inspect websockets, isn't one of them. What kind of developer makes a blanket statement like that? There are all kinds of situations where debugging is more like detective work. When you discover the problem, then you have the knowledge necessaryto actually write the test that fails and which you can then make succeed.
- latchkey 4y ago
  > What kind of developer makes a blanket statement like that? One with over 20 years of experience building software used by millions of people daily. You're trying to generalize a very specific conversation. OP was talking about building a tool to debug websockets. You don't need to debug websockets, you need to debug your code that is sending and receiving data _over_ websockets. In that case, you don't even need websockets at all. Meaning you don't need a tool to inspect the data either. Just make sure that your code is sending and receiving the correct data and you're done. Of course, if you want to build a tool, go ahead... that's your choice, but my question is still valid. Why not write tests?
  - ShroudedNight 4y ago
    If people don't have the same positive relationship with tests that you do, I could easily see "writing tests" generate enough negative sentiment to seriously degrade a person's capacity engage the near whimsical part of the brain that allows one to think laterally at non-trivial 'distance' from the obvious problem. It could easily be as simple as writing tools is more inspiring / engaging to the OP than writing tests.
    - latchkey 4y ago
      You're 100% right and that's a large part of the problem here.
    - jasonm23 3y ago
      I'll chime in here because it looks like you've had a terrible time with someone who's a [insert word of choice]. TDD "evangelism" is often toxic and abusive. The actual practice of a functioning TEAM (not just the devs) who know what it is and how it works, changes things fundamentally for the better. Spikes are used to do the "whimsical" how the F do we do Y, parts. XP devs don't TDD those and the code is usually tossed out (with the good bits used to help build the production code.) Similarly TDD isn't a religion, and only an fool would apply it like one. The good parts are, you get a test suite, you get developer examples of how to use a unit, you get an extra step to think about naming, so you're _slightly_ less likely to be saddled with a poorly thought out API / naming scheme. It's broadly useful, helps teams integrate code, much faster. Everyone needs to be playing the game, though, and they need to know the rules. C2 wiki is about the best place to find organic conversations about XP and TDD (archived though, so no sanctimonious claptrap from the likes of me), and the wide internet is a great place to get polarized. I'm sorry you got a bad taste, and it may have put you off, but a functioning TDD team is about the sanest, quickest, dev team you'll have the pleasure of working with. While, as you've found, an oppressive diktat to DO TDD PROPERLY when the team isn't really doing that, is hellish.
leptons 4y ago
>Writing a tool to inspect websockets, isn't one of them. That's assuming quite a bit and not at all true in all cases. I deal with websockets with wireless IoT devices and I can tell you that your insistence that debugging websockets doesn't require writing any custom tools is just wrong. So great, you wrote a test that passes. Your test runs it once. Maybe your test runs it twice. But what happens when the IoT device fails in an unexpected way after the 150th run? Your test isn't going to catch that. If you ran tests repetitively then your test is never going to finish in a reasonable amount of time. Do you think running the tests for an entire day is reasonable? No. That's why sometimes building a "debugging CLI" like OP wrote is needed. Not everything can always be debugged with a simple test, or any kind of test. Network congestion effects can be tricky to work out. Memory leaks in remote devices you don't control. There's a whole lot of reasons why tests aren't always the catch-all some people think they are. I'm not saying don't write tests, just don't go around suggesting they're a cure-all.
- latchkey 4y ago
  It isn't easy, but all of this can (and should) be tested. It will produce far better and more reliable code. You can certainly run tests 151 times. In fact, if you think you're going to find a bug after that many runs, a test suite is perfect for automating the execution. Don't believe me? Jespen is a great example of difficult distributed testing done well: https://jepsen.io/ https://jepsen.io/
  - leptons 4y ago
    You sound like you have TDD Stockholm Syndrome and can't fathom any other kind of software development.
    - latchkey 4y ago
      I wouldn't describe TDD as captive or abusive.
      - leptons 4y ago