Full day Cypress workshop ideas

[bahmutov]

first half - same as before

second half - new content

• [x] retry-ability and should(cb) in #29
  • these are core concepts and we have spent time adding more examples to the kitchensink and documentation sites
  • https://on.cypress.io/should
  • bringing additional assertion libraries
• Cypress & Jest (unit testing & component testing & e2e testing)
  • configuring Cypress when Jest is installed (clashing global methods like expect)
  • react-testing-library and cypress-testing-library
• [x] Custom commands in #30
  • how to write them, why to write the
  • including TypeScript definitions like example https://github.com/cypress-io/cypress-example-todomvc#cypress-intellisense
• [x] reporters
  • how to use reporters, save results #25
• Cypress module API
• [x] Cypress configuration: cypress.json, command line flags, environment variables, plugins file #32
• [x] Page objects vs app actions #40
  • based on https://www.cypress.io/blog/2019/01/03/stop-using-page-objects-and-start-using-app-actions/ and https://github.com/bahmutov/test-todomvc-using-app-actions
• GraphQL testing
  • this is becoming a must for E2E
  • probably will need to add GraphQL endpoint
  • https://glebbahmutov.com/blog/e2e-testing-graphql-using-cypress/
• [x] debugging #42
• [x] fixtures and backend with cy.task #43
• [x] bundling with your own browserify or webpack options #47
• [x] unit testing components #48

[euZebe]

Quite off topic, but I think it could be great to make tests fail by default, rather than having them pass even when not touching a single line.

Furthermore, considering I know how to use Cypress after almost a day of workshop, I would be pleased to find some test strategy advice (even if it may vary a lot from one projet to another).

[bahmutov]

@euZebe you mean the exercises in this current workshop have tests that pass by default? And that is bad? I see, although most of the tests are empty and have comments "do this A, do thing B".

under the test strategy advice, what do you mean? Which features to test? Or the breakdown between unit tests and e2e tests and when to write each type of test? I do have some content to put for this topic for sure.

[euZebe]

@bahmutov other languages' tutorials and exercices often fail, so that you clearly see that something is missing ; here is an example with Kotlin koans. I didn't think about how to make something similar, but I find it more TDD. I would be glad to help however.

About test strategy advices, I mean you can know how to write a unit test (technically speaking), if you don't know what to test, you're missing the point. It's the same with cypress and e2e tests. Here are a few examples I think about right now:

• bypass UI login for all tests but the one testing it with UI, and generally speaking, don't test twice the same thing => it can (and it is perhaps) explained when learning how to use cy.request()
• don't test twice the same thing also goes for unit vs e2e tests => any advice to isolate perimeters of each kind of test would be appreciable. For instance, should a e2e test check that a details page displays the expected data, or should it stay at a unit level ? Then what is relevant in the e2e test ?
• a practice I consider important not to make tests fail too easily: even if cypress allows you to get elements by a class selector, cy.get('.any-class'), don't use it. Classes are made to add style, which can change without changing the feature. Prefer using some rock solid selector (id, or attribute specific to tests: data-testid). More generally, for each line of e2e test, think about how it could fail and if you would really want it to fail for such reasons...
• according to the size of a project, should we test everything (probably not, unless this is a very small one) ? Should we focus on critical features (and critical ones often are valid paths) ?

Of course some of these points may be listed in the best practices, but I see that as a good reminder before finishing the workshop.

[bahmutov]

great notes @euZebe I appreciate the feedback, and yes, these are good questions. I think using good selectors is a good subtopic. Testing feature X only once goes really well into the "App actions" section (read the blog post, if you haven't already).

I would be interested if you make a pull request with a few tests in https://github.com/cypress-io/testing-workshop-cypress/blob/master/cypress/integration/05-xhr/spec.js#L59 changed to fail. Would you replace all comments with commands without arguments?