Testing functionality with cypress.io
I have fallen in love with how cypress.io lets you test the frontend functionality of my sites, it's pretty great. Please note, I am not being paid for this endorsement... its just that great.
In the past I've used C# coded solutions to test the frontend of the site where you record or author tests and they run with browser extensions or other hooks. But it's just so SLOW writing tests that way, like I burnt a couple hours a few weeks ago trying to figure out how to press enter in a textbox. The resulting answer was both un-intuative and complicated! The nice part of these tools is usually they come with recorders so you can just click around and record the results. Sounds and demo's good when you're just browsing google or static content. But in the real world you're probably using it to test more complex functionality, so 99% of the time you have to start editing find expressions, or converting the recording to code and trying to figure things out in a custom C# API.... painful.
So how does cypress make my life easier?
- It's fast... I mean REALLY fast. You use VSCode (or any editor really) to author the Mocha\Chai tests. VS auto-saves and the tests just re-run inside of a custom chrome browser that fires up all configured. That's right, no more browser extensions slowing down chrome or injecting content, or even needing to close open browsers!
- Automatic XHR waiting, so you can hook into async calls and run tests AFTER they complete and assert their results instantly.
- Open source, no more needing to pay thousands of dollars a year
- It can record screenshots OR video as it runs
- You can literally in the UI hover over each test step to see the current DOM state at that time to debug problems.
So with the above problem of the enter key, how is it handled with cypress?
It's that just beautiful? Now what if we need to test some mobile features on an iPhone6 sized screen... check this out
TADA! So now obviously you have complete control over the viewport sizing, but the pre-baked human readable device names are just a nice touch, thats polish right there.
Here's an example of testing SPA\Clientside xhr async functionality
Now if you need to test logged in functionality, I made a quick little helper controller you can use to log your test user in. PLEASE PLEASE PLEASE wrap it in some code that prevents it from being run arbitrarily. Block by IP, use a key, maybe only runs in debug or on the dev domain, but do something. The below code strips out everything I have just so it's clear what's going on.
I can't recommend this tool enough! Go have fun!
This is a front end testing suite, so it's not Sitefinity specific, test any site based on anything with it... if you need to test C# CODE, you want to be using a regular UnitTest project, or if the test needs to run in the context of sitefinity (so you can use the API, you need the test runner. Grab it at this link.