Cypress: Test sections, checkpoint reporting, or subTests

Created on 13 Apr 2018  路  6Comments  路  Source: cypress-io/cypress

Current behavior:

To get a nice list of use cases to be listed, in test results, I currently have to run a test for each use case.

Example:
Order Bike
--> Pre Login
-> Initial Bike configuration is set
--> Navigate to Catalog
--> Find Bike
--> Click
--> Assert Page

-> Bike Type unicycle hides chain option
--> Navigate to Catalog
--> Find Bike
--> Click unicycle
--> Validate sections

-> Bike Type motorcycle shows engine section
--> Navigate to Catalog
--> Find Bike
--> Click motorcycle
--> Validate sections
etc.
etc.

Desired behavior:

Be able to report on important checkpoints within the run that signify a validated use case. Where if the use case is not reached is reported as incomplete. I would also like to be able to see these checkpoints reported as tests with the time set to the current parent's time.

Order Bike
--> Pre Login
--> Navigate to Catalog
--> Find Bike
--> Click
--> Assert Page Initial Bike configuration is set
--> Click unicycle
--> Validate sections Bike Type unicycle hides chain option
--> Click motorcycle
--> Validate sections Bike Type motorcycle shows engine section

proposal 馃挕 feature

Most helpful comment

I agree this would be valuable. I expect my it cases to be self-contained and to not depend on the state left behind by previous tests. Your checkpoints would be part of a single it and thus could depend on state from before, while still providing a meaningful way to group assertions or portions of a test.

All 6 comments

example syntax

checkpoint(string, [function] = ()=> {})
if the function throws error report error and continue execution in caller
else record a successful test

if('Should run', function(){
  cy.next(); //attempt to advance to next screen
  cy.get('#requiredId').should('have.text',' \'field\' is a required field. Please select a value.');
  checkpoint('Should Enforce required'); //made it here required was enforced
  cy.get('#close').click(); //close the dialog box
  checkpoint('Should Display default By Default',function(){ //Should be displaying x and not y does not effect rest of flow if failed
    cy.get('input[name="dataTableRadio"][value="default1"]').should('to.exist');  
    cy.get('input[name="dataTableRadio"][value="Motor1"]').should('not.exist');
  });
  cy.get('#IGImage_Motor').click();
  checkpoint('Should Display Motor When Selecting Motor',function(){ //Should be displaying y and not x
    cy.get('input[name="dataTableRadio"][value="default1"]').should('not.exist');  
    cy.get('input[name="dataTableRadio"][value="Motor1"]').should('to.exist');
  });
  checkpoint('Should Display Warranty Selection' function(){
    cy.get('#Warranty_1').should('have.value', 'PS');  
    cy.get('#Warranty_2').should('have.value', '1');
    cy.get('#Warranty_3').should('have.value', '3');
  })
  cy.get('input[name="dataTableRadio"][value="Motor1"]').click(); //will error here if Motor1 doesn't exists will continue even if default1 is shown
  cy.next();
...
}

basically the idea here is that if the test run can still continue please do and collect as much as you can and fail once the flow breaks, or if a root assert fails.

What value does this offer that splitting up tests into unique it cases is not currently offering? I'd like to understand more about what you want.

As a side note, tests like the one below are unecessary, as cy.get('.el') automatically checks that the element exists and will fail without needing to assert to.exist. See Default Assertions.

cy.get('input[name="dataTableRadio"][value="default1"]').should('to.exist')

The main thing I want is to be able to say this test run satisfies the use cases A,B,C,D without having to do 4 full runs.

This avoids having to build up the state multiple times, when I'm trying to assert things, that if they don't exist isn't blocking me from continuing the run.

I like having the should ;)

Sorry I realize my desired behavior was incorrect, edited OP.

I agree this would be valuable. I expect my it cases to be self-contained and to not depend on the state left behind by previous tests. Your checkpoints would be part of a single it and thus could depend on state from before, while still providing a meaningful way to group assertions or portions of a test.

Hi! Do we have an update on this feature? I have a use case in my project for a test section.

Was this page helpful?
0 / 5 - 0 ratings