Our ATDC friends down the hall at Cypress.io have created an amazing product to help us do just that…test our Slack app in Slack. Since the main Slack app can run in a web browser, Cypress can handle our testing needs. Many of our features require multiple Lambda functions, back and forth user interaction and functionality that can only be tested through Slack. The ability to easily run our end-to-end tests was reason enough to use Cypress, but here are a few features that we really appreciate:

Easy to setup and easy to use. You add the cypress module to your package.json and you are ready to start testing. Network request management allowing better control and detection of request and response data. Screenshots for test runs, showing the test result information and the browser view at the time of the test. Videos of the entire test run. We have actually used this to discover other bugs while investigating a particular test failure.

Easy Setup and Use

Cypress has an easy setup. You can follow the simple install process here. Once its added and downloaded, you can start writing tests. I’ve used a lot of tools in my career and it’s refreshing when documentation and examples are done well. Here is a link to their example repository, what they call the kitchen sink. It has examples detailing all aspects of the tool.

Due to the simple install process and test writing, we were able to have one of our junior developers build out our tests using just the docs and examples. I don’t think that would have been the case with other products. I’ve used another tools before and to get them up and running was a challenge even for seasoned engineers.

Thankfully Slack uses Cypress best practices for making element selection easier. Most objects have a data-qa attribute. Selecting elements is less brittle because those attributes do not change as much as classes and ids might. They even have a suggested selector tool that gives you the selector data for an element just by clicking the ui. In the screenshot below you can see the selector that was created from clicking #general channel on the left.

Element suggested selector tool

Network Requests

They built their product from the ground up to completely manage the browser. This gives the tool direct access to data coming in and out of your application. Network request management is possible because they handle the entire network activity natively instead of by use of bindings and libraries that need to be installed. Since Cypress is managing that data directly, it automatically waits and gives visibility and control over that information. Waiting for network requests to complete is simple, no need for sleep timers or random waits like with other tools. Below is an example of how we wait for Slack’s dialogs to appear.

Testing settings command displays the Slack workspace name

You can even record and reply network traffic to ensure the response is correct based on the request using fixtures. Currently we’re testing that data is being sent to Slack and the messages are presented correctly so we have not used fixtures yet. We are going to investigate fixtures for our nightly alerting which is time sensitive. Being able to guarantee certain sets of data is going to make fixtures very useful.

Writing tests with Cypress is similar in nature to how we are doing our unit tests with Jest or Mocha with describe and it blocks.

Cypress example of integration testing for welcome handler

In the example above, we are looking for the input box to type our welcome slash command. Using the route network request functionality, Cypress automatically waits for the specified request to complete. We then check for the output message and ensure it contains the right information and a settings button.

Screenshots and Video

As a developer and ex-QA engineer, the screenshot and video capture features could not be more important to me. Many times it’s hard for the QA team to explain what’s happening when a test breaks. Cypress makes this a breeze. Here is an example test of our settings dialog. In the screenshot below, the Company Profile dialog expected the website url to be empty but it was populated with Matt.com.

Cypress goes one step further and actually provides the video stream of the test run! A developer can see exactly what’s happening as the test happens. Here is an example video below of what appears to be a very simple feature of our app, adding an ad account. Behind the scenes, not so much! There are a number of Lambda functions in place to ensure proper interaction with the user, proper interaction with Facebook or Google, and then making sure the user is notified accordingly. In the video, the test fails at the end because we updated messaging for the Google AdWords to Google Ads update.

Video capture showing an error because we change messaging

What’s Next

We are just scratching the surface with what we can do with Cypress. We still want to check out fixtures for our next round of testing. They have a great dashboard to see status of runs, watch replay videos, and much more.

Dashboard displaying output of successful test suite

You can also run the entire test suite headless. This allows you to push your tests into your CI/CD pipeline. Now that we have our initial test suite up and running, we will be working on that. Cypress provides docker images and examples for helping us get that working. As I mentioned, we are using AWS CodeBuild which is not one of the recipes so we are in uncharted territory...let me know if anyone else has set that up.

Thank you Cypress.io for give us such a great tool. We have enjoyed using it and can’t wait to see what you do next.

Building for other people’s products? Let us know how you get down with OPP!

Later,

Ledom

If you are interesting in seeing what we have built here at Eletype, you can check our app here in the Slack App Directory and subscribe to our product launch on Product Hunt here.