Extend Cypress with Plugins
Cypress can not only interact with our frontend code, it can also trigger events in our backend, allowing us to seed our database, assert on database snapshot, or trigger jobs like email campaigns to run.
To get familiar with this mechanism, let's build a "hello world" Cypress Plugin.
Instructor: [0:00] Most of your Cypress code will be executed in the browser. For certain types of challenges like seeding a database, sending emails, or otherwise testing the impact of jobs that might be queued as a result of your frontend interactions, you'll want to write a Cypress plugin.
[0:15] Plugins are a scene for you to write your own custom code that executes during particular stages of the Cypress lifecycle.
[0:22] Let's go ahead and write a Hello World version of a Cypress plugin to see how it works. Let's say onTask which we'll call with cy.task. We'll call the task Hello. Hello will accept a name. Finally, we'll console.log. The log statement will say Hello name. We'll return null, which for a Cypress plugin means it executed successfully.
[0:50] If we switch over to our test file, we can call this with cy.task calling the task Hello and passing a name World.
[0:59] From Cypress, we'll see the task logged out. Logging out the name of the task and the arguments we passed. If we look at our Cypress runner, we can see that Hello World gets logged out in our console. We take notice that the task took place in the command line, not in the browser and that we're going to use task to interact with our server environment.
[1:21] Also, that Cypress isn't running in our web pack server or our backend server. Cypress is running in its own execution context with its own version of node. It can't just happen to the running server. We have to trigger tasks that will do the work for us on the backend.
[1:38] In the next lesson, we'll see this in action, when we write a task to see their database.