3 ms·

> How do you test CLI? I do not understand this. Has the author used diff or stdin/stdout redirection? Testing CLI is trivial in comparison to testing a GUI or

by csb6 6y ago

> How do you test CLI? I do not understand this. Has the author used diff or stdin/stdout redirection? Testing CLI is trivial in comparison to testing a GUI or another kind of interface; it is all text and so can easily be compared against a correct result. CLIs are not meant for every task, but one of their core advantages is ease of automation and testing.

arogozhnikov 6y ago
It is easy only if you write CLI utility (or somewhat very light-weight). Imagine you write ASR system (from CLI input to output - week(s) of training, requires several servers). Mind telling me more about using diff/stdin/stdout in this case? Well, forget ASR, take any ML system.
arogozhnikov 6y ago
ok, I understand now my question got misinterpreted, I'll rewrite that. CLI parsing (mapping to real calls) may have bugs. How do you test this? Both options suggested eliminate this possibility completely. > one of their core advantages is ease of automation and testing. Any example when suggested options are any worse in this sense?
- csb6 6y ago
  I guess our conceptions of CLIs are different. I wasn't thinking of developing complex textual formats that need to be parsed as input to a CLI program, I was thinking more like simple flags like `--do-operation=value` as opposed to a button in a GUI doing the same thing. If you have a function you want to call named foo() it should be pretty easy to just look for a `--foo` flag and run it. The problem becomes trickier if you have to parse some inputs from text. However, most CLIs I've seen for third party services use mostly simple flags, each of which corresponds to some simple operation. They may take an arg or two (e.g. `cli-client --foo 34 --title "Hello"`). If there is a more or less one-to-one mapping between functions and CLI flags, then it should be pretty easy to test. Testing a full-on parser for complex CLI commands is definitely harder, though.
  - arogozhnikov 6y ago
    > then it should be pretty easy to test. If it is that simple, you can just devote this to package like typer. That's what I point to - don't write it. I see people somehow read GUI along the lines, while I never even considered that as an option. Added a note and please read completely before commenting

by csb6 6y ago

arogozhnikov 6y ago

It is easy only if you write CLI utility (or somewhat very light-weight). Imagine you write ASR system (from CLI input to output - week(s) of training, requires several servers). Mind telling me more about using diff/stdin/stdout in this case? Well, forget ASR, take any ML system.

arogozhnikov 6y ago

ok, I understand now my question got misinterpreted, I'll rewrite that. CLI parsing (mapping to real calls) may have bugs. How do you test this? Both options suggested eliminate this possibility completely. > one of their core advantages is ease of automation and testing. Any example when suggested options are any worse in this sense?

csb6 6y ago
I guess our conceptions of CLIs are different. I wasn't thinking of developing complex textual formats that need to be parsed as input to a CLI program, I was thinking more like simple flags like `--do-operation=value` as opposed to a button in a GUI doing the same thing. If you have a function you want to call named foo() it should be pretty easy to just look for a `--foo` flag and run it. The problem becomes trickier if you have to parse some inputs from text. However, most CLIs I've seen for third party services use mostly simple flags, each of which corresponds to some simple operation. They may take an arg or two (e.g. `cli-client --foo 34 --title "Hello"`). If there is a more or less one-to-one mapping between functions and CLI flags, then it should be pretty easy to test. Testing a full-on parser for complex CLI commands is definitely harder, though.
- arogozhnikov 6y ago
  > then it should be pretty easy to test. If it is that simple, you can just devote this to package like typer. That's what I point to - don't write it. I see people somehow read GUI along the lines, while I never even considered that as an option. Added a note and please read completely before commenting