Testing an existing app can be very boring. We're all trying to get humans automated out of it and let the great tools and framework do the heavy lifting for us instead. Things like Cypress and Protractor do wonders in that respect.
\nTesting an existing app due to some sort of infrastructure change is even more boring - you're forced to verify your app just because something in the technology stack or delivery pipeline's changing. So when a change like that happens and the app under change does not have a battery of tests in place, what do you do?
\nI'd suggest doing a sanity (\"smoke\") test by doing a very simple URL fetch test of the top N pages of your site, looking to get 200 response codes. Depending on your website's traffic that \"N\" can be whatever makes the most sense. In one case I took top 900 pages as they had over a 1000 page views in the last month. In another I took pages with more than a 100 page views as the site's traffic was a lot less. Either way, I'm suggesting to get some data from your analytics engine and pick a list of most visited pages from there. In case of Google Analytics, looking at the Behaviour > Site Content > All Pages, adjusting \"show rows\" to show as many as needed and than Export > CSV (at the very top of that screen). That should give you a list of pages with their relative URLs.
\nOnce we have the list of URLs that are popular, we can create a test fixture in Cypress where the URLs would be used to feed a single test.
\nTo get started with this, take the CSV you got from analytics and leave only the URL column (call it url). Then, head out to something like freeformatter.com and convert your input CSV to JSON. You should get a JSON that looks like more or less like:
\n[\n {\"url\": \"/page/1\"},\n {\"url\": \"/page/2\"},\n {\"url\": \"/page/another/a\"},\n ...\n]I call this the \"sitemap test\" so the fixture for Cypress should be called cypress/fixtures/sitemap.json.
The actual Cypress test is cypress/integration/sitemap.js and it looks like:
/**\n * to test the general structure of the site and verify that the core set of \n * pages works without a glitch - 200s, no 4xx or 5xx responses on all!\n */\ncontext('General Sitemap sanity tests (ensure main pages / most popular pages are working)', () => {\n beforeEach(() => {})\n\n it('should open pages with a 2xx response and never show the 5xx error message', () => {\n // load the fixture with the URLs we're interested in\n cy.fixture('sitemap.json').then(sitemap => {\n for(let i in sitemap) {\n // do a Cypress HTTP Request\n cy.request({\n url: sitemap[i].url,\n followRedirect: false,\n failOnStatusCode: false // we want to let the test run through the list of URLs and not stop\n })\n .then((resp) => {\n // we could verify it's 200 \n // expect(resp.status).to.eq(200)\n })\n\n }\n });\n })\n })At first I thought it may be useful to always check for getting 2xx response codes but then due to differences between QA/PROD it seemed appropriate to also just run through the list of tests and if occasional 404 happens simply ignore it. So perhaps the expect should be most useful to check for non-5xx. I'm still undecided about that last bit.
\nEither way, running through this large list of URLs gives a nice, fuzzy feeling of going through a basic sanity test for a big portion of the app and noticing quickly if something's not right due to the latest deployment push.
","excerpt":"Testing an existing app can be very boring. We're all trying to get humans automated out of it and let the great tools and framework do the heavy lifting for us…","frontmatter":{"date":"18 January, 2020","path":"/blog/basic-santity-testing-rocks","title":"On importance of simple, basic sanity testing and how Cypress fixtures can help"},"fields":{"readingTime":{"text":"4 min read"}}}},"pageContext":{}}}