If you wish to get "hands-on", you can practice adding the pokemon-go component tests.
git clone https://github.com/ShellyDCMS/cypress-test-utils-examples
cd cypress-test-utils-examples
yarn
cd examples/<framework>/pokemon-catalog
yarn
npm run build
npm run start
npm run cy:open
The driver pattern basically means that we have an additional class which is responsible of “bridging the gap” between our test file and our component. It will help our tests be unaware of the inner works of a component. In addition, if we change something in the component which causes the test to fail, we will just have to amend the driver and the tests will just pass again when the same logic works.
Every Driver exposes the following public properties
The given property will hold methods which will allow us to set pre-conditions before something takes place. This is a classic place to have methods which will set the inputs which are going to be passed down to our component.
The when property will hold methods of “events” which will take place like render, click, hover, etc.
The get property will hold methods which will give our tests access to the “output” of the component in a “black box” fashion
Just like Lego:tm:, we can create more elaborated drivers by composing them from smaller ones
Runing the front end application while mocking the backend server
Using cypress as a helper robot that behaves like a user to click around the app and verify it functions correctly
Main branch contains the following components Let's add a "pokeomon-go" component, to fetch a pokemon by index.
You can eaither practice TDD - adding another failing test every time and then making it work by adding functionnallity
Or you can add tests only to the already implemented pokemon-go component; In that case, switch to add-tests-workshop-starter
branch.
Add the following Integration test (it is an image on purpose to avoid copy&paste so you develop some "Muscle Memory")
If you get stuck, you can always take a peek at the add-tests-workshop-solution
branch
Jump to Pokemon #33 Then to #888�And then back to #33 Can you spot the difference? Let's add a test to "trap" the defect befroe we fix it
Now, fix the defect!
- Note how appart of renderning components, the tests and drivers look practically the same, regardless of weather this is a react, angular or a lit application.
- Note how using test drivers impacts tests readability and maintainability