Welcome to part one of our two part series on Angular code coverage for Cypress tests. As I have implemented more automated tests, one of the must haves for me is code coverage reports. Code coverage allow me to quickly and easily see which lines of the code are not being tested so I can close any critical testing gaps. Today, I am going to be talking specifically about how to implement code coverage for an Angular project that was generated from the Angular CLI.
Being able to schedule a post is one of the features that I miss when using Hugo for a site.
Out of the box, Hugo has no way to schedule a post as it is a static site generator which means that when you build the site the html is generated and only updated when you build the site again.
The manual workaround for the scheduling of post is to create a published post with a future date on it and then on that day, rebuild and redeploy your site. Even though this works, it depends on me to remember to do it vs it being automatic which is what I personally want. I do not want to have to remember to build and deploy the site on the day that I want a post to be published. If it depends on me, then changes are that I am going to forget or get busy and the post won’t get published when it is supposed to be.
Luckily, since I am already using Netlify to build my Hugo site and with the code for the site residing on Github, I can easily create a scheduled Github action that triggers the Netlify build for me.
Since the Angular CLI was released it has included linting using the ng lint command. With the release of Angular v11 it was announced that tslint which ng lint used behind the scenes for the linting was being replaced with eslint.
To make the migration to eslint easier for your existing project they created a couple of tools that automate almost the whole migration process for us.
I was able to finish the migration start to finish in about 30 minutes.
In your Angular application if you are using RxJS Debounce and running Cypress test you may have run into times that your tests are not consistently getting past the debounce wait time and appear like they are flaky tests.
Debounce is a way to wait X number of milliseconds for something to happen before continuing such waiting for a user to stop typing in a field before making an API call. This way you are not making an API call for each character typed into the field.
In Cypress, you could just use a wait statement to get past the debounce time but adding time based wait statements in Cypress is an anti-pattern.
Instead in Cypress you should use the cy.clock() and cy.tick() commands to be able to forward the virtual time and cause debounce to fire. However, I found it was not consistently getting past the debounce. RxJS was acting like we had not waited for the debounce time.
Luckily, after much troubleshooting the solution ended up being quite simple and only involved test code changes.
Recently, on my build servers, the Chrome version update to Chrome 95 and all of a sudden my automated builds stopped being able to communicate between Cypress and Chrome and would instantly cause Cypress to crash on the 1st test when using cypress run. We could login to the machine and run all of the tests using Chrome as a headed browser but anytime we tried to use Chrome as a headless browser it would instantly fail the build on the 1st tests.
We have seen other random issues like this show up with Chrome updates in the past and previously the fix was to disable the Chrome auto-update feature and then install a previous version of Chrome. This was a hack though as there is no supported way to downgrade Chrome.
Thankfully, there is an easier way by using a custom browser when running Cypress. Cypress even maintains a Chromium repository so that you can easily download previous versions of Chrome.