8 ms·

> I recently used Ink to build a small debugging CLI for a websocket-heavy project of mine. why not just write tests? i'm getting super down voted on this, bu

> I recently used Ink to build a small debugging CLI for a websocket-heavy project of mine. why not just write tests? i'm getting super down voted on this, but come on... why? this person built some buggy utility and those bugs can end up causing more problems than just writing tests in the first place. no wonder we end up with such buggy junk software... people... write tests!

ajkjk 4y ago
that's not what they wanted to do?
aobdev 4y ago
Automated testing and debugging are not the same
- latchkey 4y ago
  I didn't say anything about automated. 99% of the time, I debug using tests. You write the expected output and then fill in the implementation. If you don't get what you expect, something is wrong with your code and it is easy to run it in the debugger to figure out what is wrong. At the end of that, you end up with a test and some code that works. Other people call this TDD.
  - verdverm 4y ago
    most of the time, I write a small amount of code to work through or debug other's code. It's much easier to be consistent and capture more workflow in a script. Later this can be turned into tests or interfaces. Early on, the script offers much better visibility by typically having access to a debugger
    - hitchdev 4y ago
      Why not attach debugging tools to the tests?
  - rickhanlonii 4y ago
    Yeah we all know what you're talking about, you don't have to explain it. Testing is not the universally correct strategy for every case, and unless you take the time to understand their use case, you're really not in a position to understand the tradeoffs or make value statements about their work.
    - latchkey 4y ago
      If I had the choice of 'write a tool' or 'write a test'... I'd always pick write a test. Of course, that's me... which is why I asked the question in the first place. I was trying to understand their use case.
      - mixedCase 4y ago
        As you said it: Of course, that's you. But not everyone walks the same path towards robust coding, let alone coding.
  - bastawhiz 4y ago
    > it is easy to run it in the debugger Yes. They made their own purpose-built debugger. It's a tool that makes it easier to see what the program is doing. Your debugger is no more or less valid than their debugger. It's a tool, and the best tool is the one that enables the programmer to accomplish their goal. And that's what they did.
amne 4y ago
I would argue that, based on my experience, most of the code I'm debugging is not my code so it really doesn't matter how many tests I write because the problem is I misunderstood how a library or someone else's code I'm using works or there's a bug I can't find just with tests.
- verdverm 4y ago
  You're writing code against other's code, the UI seems like overhead over when you can just have a script that can effectively do the same thing. There is a term called "blackbox testing", which is more or less what we do for 3rd party code | services anyway.
aloer 4y ago
Not everything can or should be a codified test. There’s a reason postman is a billion dollar product. Just not as good for websockets Ink allowed me to quickly add a simple admin and debug UI
- vanviegen 4y ago
  > There’s a reason postman is a billion dollar product I guess so, but is it a good reason? It's a fancy ui for curl...!?
  - anon223345 4y ago
    If postman is just a fancy Ui for curl Now I’m wondering your thoughts on Burpsuite And wondering if you feel GitHub is just a fancy UI for git lol
throwaway675309 4y ago
Building a simple debugging tool to monitor your program for possible inconsistently reproducible bugs and having unit tests are not mutually exclusive concept. You're getting downvoted because you're making condescending assumptions about the developer.
- latchkey 4y ago
  I'm not being intentionally condescending. it is a valid question to ask that. i come from a strongly tdd background. i can't tell you how many times i've seen people write simple debugging tools only to have the tool be the source of the bug. ever written a println and output the wrong variable, then scratch your head why the results are wrong? websockets themselves are well debugged, similar to http. years ago, i stopped spinning up a http server just to test my endpoints. now i just call the functions directly. thus, it would be an issue with the OPs code that is sending/receiving. take websockets out of the equation and everything would work fine with tests.
  - jasonm23 4y ago
    > Come from a strongly tdd background Friend, we need to be damned careful about how we view others code when they don't have tests or embrace TDD. When we work with TDD or even a well tested codebase, we do benefit enormously. We also risk becoming evangelical, and that almost always comes across as condescending and off-putting. TDD Tests do not capture every possible point of faillure. There's clear use cases for things like Postman, Debugging Proxys, or OPs _debugging_ tool. PSA - avoid being a hype monger or evangelist of anything, it's about the worst way to support practices or tools you believe in. Trust me, I'm not only a practitioner of TDD but also a Lisp advocate and Emacs user... All these things are the best ever thing that happened /s No, the whole world won't ever be a place where everyone is "doing it right" by your estimation, or mine, or anyone else's. Quite the opposite, so settle in and mellow your jets.
    - latchkey 4y ago
      good response. i'm not being evangelical by asking a question. i'm also not trying to start a sermon. my response was to explain where i was coming from because i was being called condescending. i don't care about doing it right. i can ask why someone would write a tool, instead of using one of the existing ones... or writing tests. my jets are plenty mellow.
nkrisc 4y ago
The test failed. Ok.... why?
- latchkey 4y ago
  Exactly. Why? So you're first instinct is to write a tool to inspect websockets?

ajkjk 4y ago

that's not what they wanted to do?

aobdev 4y ago

Automated testing and debugging are not the same

latchkey 4y ago
I didn't say anything about automated. 99% of the time, I debug using tests. You write the expected output and then fill in the implementation. If you don't get what you expect, something is wrong with your code and it is easy to run it in the debugger to figure out what is wrong. At the end of that, you end up with a test and some code that works. Other people call this TDD.
- verdverm 4y ago
  most of the time, I write a small amount of code to work through or debug other's code. It's much easier to be consistent and capture more workflow in a script. Later this can be turned into tests or interfaces. Early on, the script offers much better visibility by typically having access to a debugger
  - hitchdev 4y ago
    Why not attach debugging tools to the tests?
- rickhanlonii 4y ago
  Yeah we all know what you're talking about, you don't have to explain it. Testing is not the universally correct strategy for every case, and unless you take the time to understand their use case, you're really not in a position to understand the tradeoffs or make value statements about their work.
  - latchkey 4y ago
    If I had the choice of 'write a tool' or 'write a test'... I'd always pick write a test. Of course, that's me... which is why I asked the question in the first place. I was trying to understand their use case.
    - mixedCase 4y ago
      As you said it: Of course, that's you. But not everyone walks the same path towards robust coding, let alone coding.
- bastawhiz 4y ago
  > it is easy to run it in the debugger Yes. They made their own purpose-built debugger. It's a tool that makes it easier to see what the program is doing. Your debugger is no more or less valid than their debugger. It's a tool, and the best tool is the one that enables the programmer to accomplish their goal. And that's what they did.

amne 4y ago

I would argue that, based on my experience, most of the code I'm debugging is not my code so it really doesn't matter how many tests I write because the problem is I misunderstood how a library or someone else's code I'm using works or there's a bug I can't find just with tests.

verdverm 4y ago
You're writing code against other's code, the UI seems like overhead over when you can just have a script that can effectively do the same thing. There is a term called "blackbox testing", which is more or less what we do for 3rd party code | services anyway.

aloer 4y ago

Not everything can or should be a codified test. There’s a reason postman is a billion dollar product. Just not as good for websockets Ink allowed me to quickly add a simple admin and debug UI

vanviegen 4y ago
> There’s a reason postman is a billion dollar product I guess so, but is it a good reason? It's a fancy ui for curl...!?
- anon223345 4y ago
  If postman is just a fancy Ui for curl Now I’m wondering your thoughts on Burpsuite And wondering if you feel GitHub is just a fancy UI for git lol

throwaway675309 4y ago

Building a simple debugging tool to monitor your program for possible inconsistently reproducible bugs and having unit tests are not mutually exclusive concept. You're getting downvoted because you're making condescending assumptions about the developer.

latchkey 4y ago
I'm not being intentionally condescending. it is a valid question to ask that. i come from a strongly tdd background. i can't tell you how many times i've seen people write simple debugging tools only to have the tool be the source of the bug. ever written a println and output the wrong variable, then scratch your head why the results are wrong? websockets themselves are well debugged, similar to http. years ago, i stopped spinning up a http server just to test my endpoints. now i just call the functions directly. thus, it would be an issue with the OPs code that is sending/receiving. take websockets out of the equation and everything would work fine with tests.
- jasonm23 4y ago
  > Come from a strongly tdd background Friend, we need to be damned careful about how we view others code when they don't have tests or embrace TDD. When we work with TDD or even a well tested codebase, we do benefit enormously. We also risk becoming evangelical, and that almost always comes across as condescending and off-putting. TDD Tests do not capture every possible point of faillure. There's clear use cases for things like Postman, Debugging Proxys, or OPs _debugging_ tool. PSA - avoid being a hype monger or evangelist of anything, it's about the worst way to support practices or tools you believe in. Trust me, I'm not only a practitioner of TDD but also a Lisp advocate and Emacs user... All these things are the best ever thing that happened /s No, the whole world won't ever be a place where everyone is "doing it right" by your estimation, or mine, or anyone else's. Quite the opposite, so settle in and mellow your jets.
  - latchkey 4y ago
    good response. i'm not being evangelical by asking a question. i'm also not trying to start a sermon. my response was to explain where i was coming from because i was being called condescending. i don't care about doing it right. i can ask why someone would write a tool, instead of using one of the existing ones... or writing tests. my jets are plenty mellow.

nkrisc 4y ago

The test failed. Ok.... why?

latchkey 4y ago
Exactly. Why? So you're first instinct is to write a tool to inspect websockets?