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

wdio-allure-reporter: capture before each and all hooks #3536

Merged
merged 1 commit into from
Feb 18, 2019
Merged

wdio-allure-reporter: capture before each and all hooks #3536

merged 1 commit into from
Feb 18, 2019

Conversation

mgrybyk
Copy link
Member

@mgrybyk mgrybyk commented Feb 10, 2019

Proposed changes

Capture before all and after all hooks in Allure report as tests in case:

  • hook failed
  • hook has some user defined steps attached to report with allure.addStep(...)

Capture beforeEach and afterEach hooks in Allure report as test steps.

No global hooks will not appear in report.

fix for #3517

Types of changes

  • 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 added tests that prove my fix is effective or that my feature works
  • I have added necessary documentation (if appropriate)

Further comments

Allure report example with mentioned changes

example with beforeEach failure and afterEach pass as test steps

image

example with failure in the very first before

image

more examples here #3536 (comment)

Reviewers: @webdriverio/technical-committee

@codecov
Copy link

codecov bot commented Feb 10, 2019

Codecov Report

Merging #3536 into master will increase coverage by 0.04%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #3536      +/-   ##
==========================================
+ Coverage    97.7%   97.75%   +0.04%     
==========================================
  Files         133      133              
  Lines        2969     2978       +9     
  Branches      651      655       +4     
==========================================
+ Hits         2901     2911      +10     
+ Misses         64       63       -1     
  Partials        4        4
Impacted Files Coverage Δ
packages/wdio-allure-reporter/src/utils.js 100% <100%> (ø) ⬆️
packages/wdio-mocha-framework/src/index.js 100% <100%> (ø) ⬆️
packages/wdio-allure-reporter/src/constants.js 100% <100%> (ø) ⬆️
packages/wdio-allure-reporter/src/index.js 98.62% <100%> (+0.85%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6a6e5ba...7c8a1c9. Read the comment docs.

@BorisOsipov
Copy link
Member

@mgrybyk what about jasmine adapter? Did you check that reporter works as well with wdio-jasmine?

@mgrybyk
Copy link
Member Author

mgrybyk commented Feb 10, 2019

@BorisOsipov no, Jasmine logic should not be affected at all.

Previous logic was only ignoring mocha all and each hooks.

if (!this.allure.getCurrentSuite() || ignoredHooks(hook.title)) {
    return false
// ignoredHooks checks if hook is one of
// mochaIgnoredHooks = ['"before all" hook', '"after all" hook', '"before each" hook', '"after each" hook']

I changed logic to capture only that mocha hooks and only for allure reporter.

If we need to change something in other adapters/reporters fee free to submit issue and assign to me.

@mgrybyk
Copy link
Member Author

mgrybyk commented Feb 10, 2019

If there are no comments let's merge! :)

return false
}

this.allure.startCase(hook.title)
// todo: describe what are we doing here
Copy link
Member

Choose a reason for hiding this comment

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

I suppose, it was backported from v4, as you I am no sure it is required or can be removed

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not sure as well. I'd better keep existing logic as is for now.

We can improve it in different PR

Copy link
Member Author

Choose a reason for hiding this comment

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

@BorisOsipov removed // todo: describe what are we doing here and refactored that code.

@BorisOsipov
Copy link
Member

BorisOsipov commented Feb 11, 2019

There is one issue why hooks are ignored. If you report hooks as test - it will significantly increase end user tests count - and it is bad because hooks aren't tests

@mgrybyk
Copy link
Member Author

mgrybyk commented Feb 11, 2019

@BorisOsipov why significantly?
If there are no user defined hooks report will look the same.

At least before hook in testing is called precondition which is a part of test case.

We should always show before hooks, but I can't say the same for after hooks.

We can print after hooks only if there is some error which will be useful to understand why tests have failed.

On the other hand showing before and after hooks will provide better explanation in terms of timing.

@mgrybyk
Copy link
Member Author

mgrybyk commented Feb 11, 2019

Let me hide passed after hooks.

P.s.
Ideally it should be on before all hook per suite.

@BorisOsipov
Copy link
Member

why significantly?
If there are no user defined hooks report will look the same.

In any project I worked we had before\all hooks. So if we have N tests, if we enable reporting than we will have + N tests in report - It isn't good. Also we will have misleading with e.g. spec reporter, who doens't count hooks as tests.

We should always shown before hooks, but I can't say the same for after hooks.
On the other hand showing before and after hooks will provide better explanation in terms of timing.

Yes, I totally agree with you, but it hard to implement, because AFAIK hook:start event appears earlier than test:start, so there is no started test in allure => you can't create step for reporting.

We can print after hooks only if there is some error which will be useful to understand why tests have failed.

yes it will be good. I suppose it already implemented? isn't it?

@mgrybyk
Copy link
Member Author

mgrybyk commented Feb 11, 2019

@BorisOsipov

So if we have N tests, if we enable reporting than we will have + N tests in report - It isn't good.

Actually nope, only if there are suite level before/after hooks. beforeEach and afterEach are not added as tests so they won't bother user.

I suppose it already implemented? isn't it?

Not really, have to adjust implementation so that failed after hook will be shown only in case of error.

@mgrybyk
Copy link
Member Author

mgrybyk commented Feb 11, 2019

describe
  before
  beforeEach
  it
  it
  it
  after
  afterEach

With current implementation of this PR we have in report something like that. (As you might see each hooks are not spamming report.)

before
it
it
it
after

I want to change it to

before
it
it
it
after (only in case of failure)

@mgrybyk
Copy link
Member Author

mgrybyk commented Feb 11, 2019

Is this fine? @BorisOsipov

@BorisOsipov
Copy link
Member

No, sorry. We must not report hooks as tests. It will cause misleading and question about test counts in different reporters. But I think reporting failed hooks is really important to do.

So can we make in that way?

before (report as test only in case of failure)
beforeEach(report as steps always)
it
it
it
afterEach (report as steps always)
after (report as test only in case of failure)

what do you think?

cc @christian-bromann, maybe you have some ideas

@mgrybyk
Copy link
Member Author

mgrybyk commented Feb 11, 2019

I think that part of the test should be reported explicitly.

However I agree that there will be questions to test count, so I should not show hooks as tests.

As a conclusion: if I won't be able to add before as test step properly I'll only shown that hooks in case of failures as you've suggested.

@BorisOsipov
Copy link
Member

@mgrybyk 👍

@mgrybyk
Copy link
Member Author

mgrybyk commented Feb 11, 2019

@BorisOsipov behavior is now simplified:

beforeEach/afterEach hooks are added to test as steps

all the other hooks (mocha before/after or whatever) are added as tests only in case of failure or if hook has steps (added with allure.addStep(...)).

Steps are controlled by user, in order to have passed hook in report user has to trigger allure.addStep(...) in before/after or any other hook (except of mocha beforeEach or afterEach of course).

@mgrybyk
Copy link
Member Author

mgrybyk commented Feb 11, 2019

example with added user step in before hook

  before(() => {
    browser.url("https://google.com.ua")
    reporter.addStep('user added step in before', undefined, 'passed')
  })

image


example with no user steps in before and failed after hook
image

@mgrybyk
Copy link
Member Author

mgrybyk commented Feb 14, 2019

@BorisOsipov so you have some more comments?

@BorisOsipov
Copy link
Member

BorisOsipov commented Feb 14, 2019 via email

Copy link
Member

@BorisOsipov BorisOsipov left a comment

Choose a reason for hiding this comment

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

Awesome 👍

packages/wdio-allure-reporter/src/index.js Show resolved Hide resolved
packages/wdio-mocha-framework/src/index.js Show resolved Hide resolved
@christian-bromann christian-bromann added the PR: Polish 💅 PRs that contain improvements on existing features label Feb 18, 2019
@christian-bromann christian-bromann merged commit 4aae6be into webdriverio:master Feb 18, 2019
@mgrybyk mgrybyk deleted the allure-reporter-capture-mocha-hooks branch February 21, 2019 12:20
yamkay pushed a commit to MoveInc/webdriverio that referenced this pull request Jun 13, 2019
yamkay pushed a commit to MoveInc/webdriverio that referenced this pull request Sep 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: Polish 💅 PRs that contain improvements on existing features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants