3 ms·

>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 Io

>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
      It's definitely captive depending on who leads the team. I've done it before. And it can be abusive if the CTO demands 100% code coverage. It gets to the point where writing any test, even a bad one is better than delaying a release just for the sake of "100% coverage". And that was at an early-stage startup where we had to move fast - and guess what, they went out of business in 6 months because we couldn't get any kind of product out. It was hilariously stupid to demand 100% code coverage on a startup without any product. TDD and testing isn't a cure-all, and in some cases it's a curse.
      - latchkey 4y ago
        Your CTO was captive/abusive, not TDD. You're describing your own SS and trying to equate that with "all TDD is bad". I said nothing about 100% test coverage or poor management skills.
        leptons 4y ago
        In my case, TDD was absolutely the problem with the dev team failing to be able to deliver in a timely way - it wouldn't have matter if the CTO mandated 100% test coverage or 75%. Anyone who thinks TDD doesn't slow a team down to a crawl is just fooling themselves, hence the Stockholm syndrome. In my view, TDD is bad for most projects, but tests are not. TDD is putting the cart before the horse. Tests should be written once the functionality is working well. Then write tests. There are very few kinds of development where TDD is the right way to go, and they involve launching space shuttles, designing medical equipment, and operating nuclear power plants. Launching a social media site? No, just no.

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
    It's definitely captive depending on who leads the team. I've done it before. And it can be abusive if the CTO demands 100% code coverage. It gets to the point where writing any test, even a bad one is better than delaying a release just for the sake of "100% coverage". And that was at an early-stage startup where we had to move fast - and guess what, they went out of business in 6 months because we couldn't get any kind of product out. It was hilariously stupid to demand 100% code coverage on a startup without any product. TDD and testing isn't a cure-all, and in some cases it's a curse.
    - latchkey 4y ago
      Your CTO was captive/abusive, not TDD. You're describing your own SS and trying to equate that with "all TDD is bad". I said nothing about 100% test coverage or poor management skills.
      - leptons 4y ago
        In my case, TDD was absolutely the problem with the dev team failing to be able to deliver in a timely way - it wouldn't have matter if the CTO mandated 100% test coverage or 75%. Anyone who thinks TDD doesn't slow a team down to a crawl is just fooling themselves, hence the Stockholm syndrome. In my view, TDD is bad for most projects, but tests are not. TDD is putting the cart before the horse. Tests should be written once the functionality is working well. Then write tests. There are very few kinds of development where TDD is the right way to go, and they involve launching space shuttles, designing medical equipment, and operating nuclear power plants. Launching a social media site? No, just no.