Skip to content

Should the UITestRunner have alwaysRun set on afterMethod? #151

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

Open
davecpayne opened this issue Mar 9, 2020 · 4 comments
Open

Should the UITestRunner have alwaysRun set on afterMethod? #151

davecpayne opened this issue Mar 9, 2020 · 4 comments
Labels

Comments

@davecpayne
Copy link

Describe the Issue
I've found that if an exception is thrown in the setUpClass or setTestName methods (annotated with @BeforeClass and @BeforeMethod respectively) of UITestRunner, then the subsequent test(s) are skipped, and so the afterMethod method doesn't execute. This meant that the Chrome session didn't get killed.

Adding alwaysRun=true to the @AfterMethod annotation seems to have resolved this issue.

Is there any downside to that which I might be missing? If not, I'm happy to submit a PR with that change in.

To Reproduce
Steps to reproduce the behavior:

  1. Set up a BDD test project using Chrome as the browser.
  2. Cause an exception to be thrown during one of the @Before... methods in UITestRunner.
  3. Execute the UITestRunner.

Expected Behaviour
The test(s) should be skipped, and the Chrome session should be closed gracefully.

Versions (please complete the following information):

  • Frameworkium-core version: [e.g. 3.0.0]
  • OS: CentOS 7.6.1810
  • Browser: Chromium
  • Version: 71

Additional Context
Add any other context about the problem here.
I originally raised this in the Frameworkium BDD project's issues, but just realised that maybe they don't get much attention. Happy to delete either that one or this one

@Mjl33
Copy link
Member

Mjl33 commented Mar 10, 2020

Hi davecpayne,

This is definitely a bug. Please go ahead with a pull request and we will merge it in

@davecpayne
Copy link
Author

Done with PR here: Frameworkium/frameworkium-bdd#15

@davecpayne
Copy link
Author

The build on the above PR seems to be failing for unrelated reasons - possibly to do with the browser version?

@Mjl33
Copy link
Member

Mjl33 commented Jan 5, 2021

I've migrated to from TravisCI to github Actions. The CI workflow is a lot more stable. If you would rebase this onto the current master, it should pass the build (barring any real test failures).

Optionally I can take over and do that for you.

@Mjl33 Mjl33 added the bug label Jan 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants