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.
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
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.
Most helpful comment
I agree this would be valuable. I expect my
itcases to be self-contained and to not depend on the state left behind by previous tests. Yourcheckpoints would be part of a singleitand thus could depend on state from before, while still providing a meaningful way to group assertions or portions of a test.