Shelex / cypress-allure-plugin

cypress plugin to use allure reporter api in tests

Home Page:https://shelex.github.io/cypress-allure-plugin-example/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Do not log specific cy commands

vjacheslavl opened this issue · comments

Hello!

Is your feature request related to a problem? Please describe.
I have tests, that intercept (cy.intercept with cy.wait) a lot of network requests, and the application under that does a lot of HTTP calls

As result, my test case report is very much full of steps with these two commands and is hardly readable

Describe the solution you'd like

I see the following options as solution:

  • Be able to exclude specific commands (cy.intercept as a whole) from logging into the allure
  • Be able to wrap code with something, that will silence the reporting of it in allure
  • Be able to log only failed cy.intercept cy. wait

Very much open to other ideas

Thank you

Hi.
Thank you for opening feature request, yes it makes sense.
Published it in v2.35.0 release, here are the details:

Be able to exclude specific commands (cy.intercept as a whole) from logging into the allure

implemented as configuration env variable, example:

allureAvoidLoggingCommands: ["intercept", "myCustomCommand"]

This way commands cy.intercept and cy.myCustomCommand will not be tracked thus will not be logged as steps.

Be able to wrap code with something, that will silence the reporting of it in allure

implemented such api, example:

// disable tracking cypress commands:
cy.allure().logCommandSteps(false);
cy.login(username, password);
cy.log('veryverysecretinfo');
// enable tracking cypress commands back again:
cy.allure().logCommandSteps();

So commands between disabling logs and enabling them back will be ignored.

Be able to log only failed cy.intercept cy. wait

This part may be tricky, as everything that happened in las vegas allure - remains in las vegas allure. I mean information that command is failed happens when command has a step in allure already, so we can not remove commands in the end of the test as it may break the chain of steps and their nested structure, as well as just take some previous data with failed information and put it inside the steps tree. Anyway, error will be logged and it is up to user what steps to ignore, this is not a very crucial feature for debugging.
There is also an option to remove steps in some post-processing function of generated json results, but I would like to avoid this approach (reading files, parsing every json, going through steps, removing steps, writing changes back to the file, etc.).

Hope that would help with your use-case.