Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

#900 Add tests for events on Terminal #1646

Merged
merged 6 commits into from Sep 8, 2018

Conversation

peacefullatom
Copy link
Contributor

@peacefullatom peacefullatom commented Sep 1, 2018

Here is my version of tests for events.

Honestly, don't know how to implement tests for 'blur' | 'focus' | 'linefeed' | 'selection', because they are emitted from outer components.

Please, let me know if I can add/improve something. 馃槂

Fixes #900

Copy link
Member

@Tyriar Tyriar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! The only thing is that I think all the tests should be async with the done handler happening inside them. While some currently would happen synchronously, this will future proof us as we typically don't make a guarantee that these things will happen sync.

expect(event).to.be.an.instanceof(Object);
});

term.keyDown(evKeyDown);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test needs to be asynchronous and verify both events pass, as currently it will pass if key and keydown don't fire

expect(event).to.be.an.instanceof(Object);
});

term.keyPress(evKeyPress);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test needs to be asynchronous and verify both events pass, as currently it will pass if key and keypress don't fire

assert.equal(typeof data.start, 'number');
assert.equal(typeof data.end, 'number');
});
term.refresh(0, term.rows - 1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test needs to be asynchronous and verify the event happens (add done to end of event listener)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After additional investigation, I've found out that refresh is a dummy function.

Next thing is that the MockRenderer also does not implement any functionality.

There are two ways:

  1. Extend mock functionality (because we're unable to use real renderers due to lack of window object, etc).
  2. Skip implementation of this test completely or implement a dummy test.

Don't know which one is preferable. 馃槂

assert.equal(typeof data.cols, 'number');
assert.equal(typeof data.rows, 'number');
});
term.resize(1, 1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add done to end of event handler

term.on('scroll', (ydisp) => {
assert.equal(typeof ydisp, 'number');
});
term.scroll();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add done to end of event handler

term.on('title', (title) => {
assert.equal(typeof title, 'string');
});
term.handleTitle('title');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add done to end of event handler

@Tyriar Tyriar added this to the 3.8.0 milestone Sep 2, 2018
@Tyriar Tyriar self-assigned this Sep 2, 2018
@peacefullatom
Copy link
Contributor Author

peacefullatom commented Sep 4, 2018

List of questions I have right now.

  1. What is a preferable way to implement a test for refresh event: skip the test, create a dummy test, extend mock functionality?

  2. Is it possible to add a sinon library to a project (including @types/sinon)? Because it will enable us to write more elegant tests with an ability to show more meaningful error messages for keypress and keydown events. Because if the test will remain like it is now it will be impossible to show a relevant error message, the only thing a user will see in case of some error is a message about a timeout.

Or, maybe, you can give me a hint to some other solution?

Thanks in advance 馃槂

@Tyriar
Copy link
Member

Tyriar commented Sep 8, 2018

@peacefullatom sorry about the delay 馃槄

  1. Probably just don't bother with that one as it's fired from the renderer and we don't really have a good story for testing when the DOM is involved heavily (yet).
  2. I think the error message is fine as it fairly accurately describes what happened (no event was fired, it timed out waiting). What are some other wins would the lib give? I don't think we should pull in another lib if the benefits are very limited as it complicates thing and it's another thing people need to learn.

Copy link
Member

@Tyriar Tyriar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@peacefullatom also I'm happy to merge this now if tests pass 馃槂

@Tyriar Tyriar merged commit 7ef18cc into xtermjs:master Sep 8, 2018
@peacefullatom
Copy link
Contributor Author

No problem! 馃槂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants