Add e2e tests

[d3lm]

I think we should really have some e2e tests for this project to ensure that, when new features are added, we don't break existing functionality.

My preference would be to write mostly e2e tests for the checklist with Cypress. Cypress a fast and reliable testing framework and I have been using it for some of my projects. It really is reliable and writing tests is fun as well.

Here's a list of todo's that we could parallelize across multiple people.

1. Set up Cypress
2. project page
   • adding projects
   • editing
   • renaming
   • and deleting
3. checklist page
   • check / uncheck items
   • add / remove favorites
   • edit mode (check / uncheck categories, test if a popup is shown when the category has favorites, test if the content area is not actionable and no items can be toggled)
   • change project
   • search for items and categories
   • filter items
   • check / uncheck all
   • about dialog

If anyone wants to take some parts over, I am more than happy to provide assistance and help you out with getting Cypress up and running.

[geromegrignon]

I'll give it a try (great way to learn Cypress).

[d3lm]

Yay, this is good news! Thanks @geromegrignon for giving this a try. Let me know if I can help you with anything. You can look at my library for some inspiration. Make sure to add a TypeScript preprocessor using the @cypress/webpack-preprocessor package. I would definitely want the tests to be written in TypeScript. Also, remove all the Protractor stuff from the project. Important for the setup is a tsconfig.json inside the cypress folder.

Again, let me know if you need help with this.

Oh and, keep your commits as small and focused as possible. This makes it easier to review your PR and all the changes. For example, the first commit should be set up cypress, etc.

[d3lm]

@geromegrignon How about I take care of the setup and you and some other people can work on the tests itself? Because there was also someone else on Twitter that was interested and I thought that we could make this a collaborative effort. Maybe you could work on the projects page and @IxquitilisSaid could work on the checklist or vice versa. But I suggest that we coordinate this here, not that multiple people work on the same tests. Then we have to discard PR and I don't want you guys to spend time on a PR that later needs to be closed without merging.

How does that sound? Do you have a preference as to what you'd like to test? If you want you can also do the setup, but I'd really like to help.

[geromegrignon]

I almost completed the setup part with TypeScript so I'll make a pull request if you don't mind (it'll be a great help to know if it's allright). I would be happy to share this part. I have no preference.

[geromegrignon]

I'll start to work on 'project page' tomorrow.
Would you prefer a pull request once it's fully done or as soon as i implemented the first test to be able to discuss about changes gradually?

[KwintenP]

Hi @geromegrignon!

I would try to keep PR's as small as possible. The sooner you submit something, the sooner we can provide feedback. :)

[KwintenP]

Btw, I'm gonna make sure the tests are run on Travis during every build as well. I'll create a PR for that asap.

[d3lm]

Thanks @KwintenP.

@geromegrignon As Kwinten already said, please feel free to send in WIP PRs. Those are totally fine. The sooner you commit something, the sooner we can give feedback and review your code.

[geromegrignon]

For each PR, i'll wait the review to add data-cy attributes to target DOM elements as a best practice.