add simple e2e tests using Cypress

[bahmutov]

1- Make sure to commit it to the dev branch!
2- Read https://github.com/alvarotrigo/fullPage.js/wiki/Contributing-to-fullpage.js

This branch adds end to end tests with a GUI using cypress.io test runner.

Example test

it('loops horizontally', () => {
    slide.down()
    checkActiveSlide('Only text')
    slide.right()
    checkActiveSlide('And text')
    slide.right()
    checkActiveSlide('And more text')
    slide.right()
    checkActiveSlide('Simple Demo')
    slide.right()
    checkActiveSlide('Only text')
  })

Example GUI during testing

Test run recording (built-in) at https://youtu.be/Yzodhs8MayA

For more info about this E2E test runner

• https://www.cypress.io/
• https://github.com/cypress-io/cypress

[bahmutov]

I will add NPM e2e test script (should start http-server to serve the current folder, run Cypress), and for this open source project we can even setup free dashboard to store videos and screenshots on failures https://www.cypress.io/dashboard/

[bahmutov]

I add test scripts (npm test for headless CI and npm run test:gui for working locally while tests are watching and running). I also setup TravisCI on my repo https://travis-ci.org/bahmutov/fullPage.js and Cypress dashboard free public project that has recordings and any test failure screenshots: https://dashboard.cypress.io/#/projects/p7bh2z/runs

[bahmutov]

@alvarotrigo any thoughts on adding e2e tests using Cypress?

[alvarotrigo]

Hi @bahmutov! Thanks for the pull request! Although I won't consider merging it as it is now.

I would really like to see the power of the tool, something perhaps more complex than texting scrolling to certain sections or slides? Why should I go for cypress instead of QUnit?

Few things if you plan to create another PR:

• Do not change docs at this point, as I might not agree with some of the changes in the structure and therefore merging it all makes no much sense. Bit by bit :)
• Can't you just create a fixture file instead of using examples files to test on? Then create different initialisations of fullPage.js within the test ?
• No need to do things like getAction('moveSectionDown').click(). That's just calling the library's method $.fn.fullpage.moveSectionDown.

[bahmutov]

Sure @alvarotrigo you control what gets changed. I was just trying to describe everything, but it can be done step by step.

• don't you want to test your examples to make sure they work as you think they are working?
• getAction('moveSectionDown').click() goes through the buttons on the examples, while $.fn.fullpage.moveSectionDown would use the jQuery plugin API. I consider these different types of tests (kind of like API vs UI). Sure one can test both!

As far as overall power - you can see what Cypress is doing during the test, which is kind of hard to do using QUnit. It also intelligently waits for assertions, so the tests do not need wait(...) statements.

[alvarotrigo]

I'm not currently interested in testing the examples. They barely get changed.

My priority at the moment would be to test all the features provided by the library to make sure I do not break anything after any change (and perhaps even test private methods, as I want to make sure they don't break at any point, possible using this method?)