How to organise test-cases into test-suites for large applications

Question

I have started writing some test-cases for an existing cart application. Have no prior experience with cypress or any other js testing framework.

Few initial test-cases I have written look like:

cart_onload_spec.js:

describe('Cart load spec', () => {

    it('Has correct page title', () => {})

    context('When cart is empty', () => {

        it('Empty cart message appears', () => {})
        it('Has correct grand total', () => {})
        it('Has correct remaining customer points', () => {})
    })

    context('When cart is not empty', () => {

        context('Line items listing', () => {
            it('Has correct column info per row', () => {})
            it('Each row shows correct row total', () => {})
        })

        it('Has correct grand total', () => {})
        it('Has correct remaining customer points', () => {})
    })       
})

cart_delete_spec.js:

describe('Cart delete spec', () => {

    before(() => {
        //empty cart
        //add 1 item
    })

    it('Can delete item', () => {
        //cy.request('/api/deleteLine')
        //assert refkey is the same as row deleted
    })

    //now cart is empty so run "When cart is empty" test-cases from "Cart load spec" again.
    it('Empty cart message appears', () => {})
    it('Has correct grand total', () => {})
    it('Has correct remaining customer points', () => {})

})

cart_update_quantity_spec.js

describe('Cart quantity updated spec', () => {

    before(() => {
        //empty cart
        //add 1 item
    })

    it('Can update quantity', () => {
        //cy.request('/api/updateLineQty')
        //assert refkey is the same as row updated
        //assert input has updated qty
    })

    it('Has correct row total per row', () => {})
    it('Has correct grand total', () => {})
    it('Has correct remaining customer points', () => {})

})

Now I can see that few it blocks can be re-used to create different scenarios or test-suites. Like in above examples it blocks repeated are

it('Has correct row total per row', () => {})
it('Has correct grand total', () => {})
it('Has correct remaining customer points', () => {})

Now, Cypress allows you to use ES6 imports. But I cannot do something like:

it('Has correct row total per row', hasCorrectRowTotal())

and define hasCorrectRowTotal() in some external file because cypress commands need to be inside it blocks per cypress documentation.

So what is the best way to manage & organize large number test-cases which can allow for testing of various scenarios by mixing & matching various smaller repeated test-cases defined at one place not copied to each spec.js file that requires it?

Answer 1

This is a pretty broad topic but I have some things that I think would be helpful to you. Comment on this answer if you would like me to clarify or add something.

Identify repeating words and consolidate
One example would be "cart". If that word is repeated at the beginning of every test spec, then create a directory called cart and put all the cart test specs in there. Nesting various things in this fashion can be helpful. If the file is located in a directory called "cart", you can remove it from the name.

Don't over/under nest
Trying to over organize can leave you more confused. Those Matryoshka_dolls come to mind( https://en.wikipedia.org/wiki/Matryoshka_doll ). Nest things as you need to. The same is true for abstracting things into page objects. Over or under abstracting can make things more confusing.

Avoiding cascading failures
Be careful not to write you test in a way that if one it fails, the following its will fail. You also won't get proper retires if you don't respect potential cascading failures. This is a double edged sword as well. If you only have one it per spec, test execution times will grow. If you have made good decisions with how you break apart your test specs and still need to improve execution time, look into parallelization: https://docs.cypress.io/guides/guides/parallelization.html#Splitting-up-your-test-suite

Shared/Common methods
You can use Page Object Modeling(acceptable to use but sometimes referred to as an unnecessary abstraction/anti-pattern) to make your code reusable. Basically you have external files that you pull in(as an instance to allow for parallelization) and reference those methods in your test specs so that your test can remain DRY(Don't Repeat Yourself). Your fellow developers will respect your effort to follow the Object Oriented Programing Principals. DRY is one of them.

Cucumber for ease of reuse and readability
Consider using Cucumber syntax/testrunner if you have a ton of repeating test logic with different permutations. Each "step" or Given/When/Then is backed by code. You can use regex to allow for parametrization.

Hope this helps! Organization is something you will continually revist and refactor your code. Each team will have different needs. Approach this in a very collaborative fashion with all interested parties providing feedback. Godspeed!