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

Fixes tests' incorrect use of .throw() assertion #6455

Merged

Conversation

usmonster
Copy link
Contributor

@usmonster usmonster commented May 1, 2016

Proposed changes

This fixes some bad test cases. (Some minor refactoring was required for the tests that were failing.)

Types of changes

What types of changes does your code introduce to Appium?

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

  • I have read the CONTRIBUTING doc
  • I have signed the CLA
  • Lint and unit tests pass locally with my changes
  • I have added tests that prove my fix is effective or that my feature works (not applicable)
  • I have added necessary documentation (if appropriate) (not applicable)
  • Any dependent changes have been merged and published in downstream modules (not applicable)

Further comments

A couple open questions/concerns about the changes I made:

  1. I needed to put the parser instances in debug mode to make sure they don't quit the entire process when checking for a thrown exception. I do this in a kind of hacky way, i.e. by directly setting p.debug = true;... Unless we can live with that, a better way might be to add an argument to getParser() that takes a boolean (or an options hash), which could allow us to pass along the debug flag in a cleaner way. What do you think?
  2. I only touched one file in this PR, since I made the same fix in another file as part of Allows --desired-caps to be passed a filename #6451. Should I still include the fixes from the other file in this PR, since one never really knows whether or not a PR will be approved, and it logically fits with this one as well?

Reviewers: @imurchie, @jlipps, ...

As pointed out in #6451, there are many test cases that do
should[.not].throw instead of should[.not].throw(), which is
incorrect and will never fail.

This fixes those incorrect uses of the method as well as refactors/fixes
the tests that turned out to be actually failing.

As pointed out in appium#6451, there are many test cases that do
`should[.not].throw` instead of `should[.not].throw()`, which is
incorrect and will never fail.

This fixes those incorrect uses of the method as well as refactors/fixes
the tests that turned out to be actually failing.
@moizjv
Copy link
Member

moizjv commented May 1, 2016

Can one of the admins verify this patch?

process.version = 'v0.9.12';
checkNodeOk.should.throw;
checkNodeOk.should.throw();
process.version = 'v0.1';
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Please let me know if you'd prefer to separate these new assertions into separate test cases.

Copy link
Contributor

Choose a reason for hiding this comment

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

This is fine.

@imurchie
Copy link
Contributor

imurchie commented May 2, 2016

I'm fine with just setting the debug flag in the test, but I also wouldn't mind if the getParser method were updated.

As for the parts in a different PR: I would not repeat them. It would make merging more difficult in the long run.

@imurchie
Copy link
Contributor

imurchie commented May 2, 2016

I'm good with this as-is. Thanks for taking this on!

@imurchie imurchie merged commit 9c1b85f into appium:master May 2, 2016
@jlipps
Copy link
Member

jlipps commented May 2, 2016

👍 thanks @usmonster. Guess we forgot to make sure our tests failed before they passed!

@imurchie
Copy link
Contributor

imurchie commented May 3, 2016

Yup. The problem with post hoc tdd.

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.

4 participants