Write your feedback here!

[tony-go]

Hey 👋

Let me know if you'd see any kind of improvement regarding the API or the purpose of this package.

Improvements:

• [x] Handle lists and selects
• [x] use string only in .type()
• [x] use another name than type => (input)
• [x] add a .skip(length: number) method
• [x] add and timeout options
• [x] rename expectFailure -> expectError
• [x] add a code parameter for exepectError
• [x] handle multiple line for exepectError and expect (array of string of regexp)

[capitnflam]

I'm not a fan if the idiom new Clic().expect, I would rather prefer the API to bé a simple fonction liké clix().expect. In way less words : hide the new.

Allowing to check the error output would be nice.

Allowing to check the returned code would be nice also.

The .type method should only accept strings as input as this is what you get when reading the input stream in a cli.

[tony-go]

Thanks a lot for this feedback @capitnflam. I have already extract a few points :)

I have two remaining question marks:

Allowing to check the error output would be nice.

I already mention that:

async scenario.run(): Promise
Will run the program and will assert all assertions registered before.

The ClixResult object stand for:

interface ClixResult {
  ok: boolean;
  val: {
    expected: string | number,
    actual: string
  };
};

Is the val property doesn't make the job?

Allowing to check the returned code would be nice also.

Could you give me a bit more on this one?

[capitnflam]

Thanks a lot for this feedback @capitnflam. I have already extract a few points :)

I have two remaining question marks:

Allowing to check the error output would be nice.

I already mention that:

async scenario.run(): Promise
Will run the program and will assert all assertions registered before.

The ClixResult object stand for:

interface ClixResult {
  ok: boolean;
  val: {
    expected: string | number,
    actual: string
  };
};

Is the val property doesn't make the job?

What I meant was that you have usually 2 output streams:

• Standard output
• Error output

A lot of CLI tools will use the error output stream to print error messages

Allowing to check the returned code would be nice also.

Could you give me a bit more on this one?

For example in JavaScript, the number you five to the process.exit fonction will be the error code that will be returned to the process that launched it. It is used to tell if the program finished properly or if there was an error. For example diff will return 0 if the two files are the same and another number if they are différent.

[capitnflam]

@tony-go Here is an example to show the 2 different output streams:

$ cat foo.js
console.log('standard output')
console.error('standard error')
$ node foo.js
standard output
standard error
$ node foo.js > /dev/null # redirect standard output to a black hole
standard error
$ node foo.js 2> /dev/null # redirect standard error to a black hole
standard output

[tony-go]

Okay @capitnflam, so regarding the streams you propose that I store both outputs somewhere and give access to them for debugging purposes? Otherwise, I want to abstract them as much as possible. (ATM)

If I joined this idea with your idea about the error code I should have

interface ClixResult {
  ok: boolean;
  val: {
    expected: string | number,
    actual: string
  };
  internals?: {
    code?: number;
    stdoutBuffer?: string;
    stderrBuffer?: string;
  }
};

For "performance" purposes I think that the internals property could be generated only if a debug option is filled.

clix('ls -la', { debug: true })

WDYT?

[capitnflam]

Okay @capitnflam, so regarding the streams you propose that I store both outputs somewhere and give access to them for debugging purposes? Otherwise, I want to abstract them as much as possible. (ATM)

I was more thinking of 2 expect methods :

• .expect for the standard output or .out
• .expectError for the standard error or .err

Both streams usually have different flushing strategies meaning that there is nothing that garanties that aggregating both will yield the same result every time.

If I joined this idea with your idea about the error code I should have

interface ClixResult {
  ok: boolean;
  val: {
    expected: string | number,
    actual: string
  };
  internals?: {
    code?: number;
    stdoutBuffer?: string;
    stderrBuffer?: string;
  }
};

For the code I think that it should be possible to specify it in the scenario. Of course if it's not specified it uses 0 by default. For example:

clix('command')
  .expect('hello')
  .type('123')
  .expectError('ERROR: number too big')
  .status(1)

For "performance" purposes I think that the internals property could be generated only if a debug option is filled.

clix('ls -la', { debug: true })

WDYT?

[tony-go]

Thanks a lot @capitnflam

I just pushed an update. I prefer to handle the error code in an inline mode.

I drop the debug mode atm.

[tony-go]

Think we reach something!

[tony-go]

I'll start something on a v0.0.1 branch ^^

You can continue to add comment anyway :)

[tony-go]

A version 0.0.2 is on the way. Please visit this pull request to see fixes and improvements.