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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve test coverage #139

Open
breandan opened this issue May 29, 2017 · 3 comments
Open

Improve test coverage #139

breandan opened this issue May 29, 2017 · 3 comments

Comments

@breandan
Copy link
Collaborator

breandan commented May 29, 2017

We need unit tests covering AceJump functionality, Swing UI and IntelliJ Platform interactions. For more information, please see the SDK Docs section on testing plugins.

edit: Please check out AceTest for some examples of unit tests we have already implemented to get a feel for how these work.

@tedyoung
Copy link

tedyoung commented Jun 1, 2017

This is wide open, any suggestions on where to start, e.g., bug-prone areas?

@breandan
Copy link
Collaborator Author

breandan commented Jun 1, 2017

Finder has a lot of subtle bugs. The main problem we have is ensuring there are no tag collisions. A tag collision occurs when there are multiple indices (ie. characters) on the screen that can be reached using the same string of text.

For example, suppose the user activates AceJump, then types some random string queryio, and there is more than one index that can be selected using that string:

query[IO]
...
queryi[OP]

This is a tag collision, since queryio can be (1) a completed jump to the first instance, or (2) a partially completed jump to the second instance. A simple test case would just verify that there are no two tags with the same letters.

query[ZX]
...
query[ZX]

This would be a tag collision, since yzx would be two separate jumps. Another test might verify that no tag is assigned a string that occurs in plaintext. If the user typed yvb below, this would result in a tag collision.

query[VB]
...
y[CX]vb

I am inclined to use some property testing tool to generate lots of random text, and random inputs, but feel free to implement this however you like. Alternately, some integration tests would be a welcome addition, particularly ones that pass keystrokes to the running IDE and validates the cursor jumps to the correct position. Happy to provide feedback if you have any questions. Thanks!

@breandan
Copy link
Collaborator Author

Additional performance tests which cover representative filetypes are needed as described in #339. Test should be accompanied by a file in src/test/resources/ containing the editor text. This would allow us to empirically test proposed performance improvements. A performance revision should be able to demonstrate positive latency deltas on all or a majority of common filetypes that AceJump users might encounter in the real world.

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

No branches or pull requests

2 participants