DEV Community: Brett Cassette

Let's Build a Web Scraper with Cypress!

Brett Cassette — Fri, 12 Apr 2019 17:06:07 +0000

What would you build if you had a web scraper?

Maybe your fitness tracker has no public API?
Or you want to always outprice your competitors?
Maybe you want to correlate and visualize data from multiple, disconnected platforms?
Want to automate common tasks on an external site?

Or maybe you're like me, and the website that lists all your open mic comedy events doesn't have any ability to search, filter, or show event locations on a map.

So how do we ingest this data for fun and profit?

Cypress to the Rescue

Cypress is a blazing-fast end-to-end testing framework. Since it can interact with any webpage, we can also use it to automate interactions with external sites!

Build it along with me in this free lesson on Egghead.io!

High Stakes Poker

Brett Cassette — Thu, 21 Feb 2019 15:11:36 +0000

This article is part of my Testing from First Principles series. If you enjoyed this series, stay tuned for practical testing advice on my Cypress End-To-End Testing course on egghead.io

If you're always playing poker for very high stakes, sometimes you're gonna get burned for very high stakes.

Especially when you're trying something new (like launching new code), doesn't it make sense to play for lower stakes?

If the worst case scenario for your code is: "no customers can checkout all day," then we can use modern tools like A/B test groups to make sure your code was only released to 1% of customers, drastically reducing our risk. Now your worst case scenario is reduced to "1% of users couldn't check out all day."

But how can we get alerted earlier, so our outage isn't all day long? With dashboard tools like AppOptics or Amplitude, and automated alerts from the likes of PagerDuty or Pingdom, we can detect anomalous behavior sooner, as long as we define in advance what our metrics are.

When an anomaly is detected, we can rely on our feature flipper library of choice to turn off the code path for everyone. Maybe we've reduced our outage from "No one could check out all day" to "1% of users couldn't check out for 1 minute."

A much better scenario.

Testing is just one of the ways we can feel confident about our code. The more we can decrease our maximum risk, the less we stand to lose. Think of it like portfolio diversification.

I think it's important that we start out by giving ourselves the lowest possible stakes--the least worst case scenario to start from before we even begin evaluating the value of testing. Why would you want every deploy to potentially risk losing the company a bunch of money?

Before you even begin testing, remember to weigh what's at stake, and consider what alternative approaches you can use to mitigate your risk. When testing is essential for code confidence, make sure your tests aren't providing a false sense of security

This article is part of my Testing from First Principles series. If you enjoyed this series, stay tuned for practical testing advice on my Cypress End-To-End Testing course on egghead.io

Are Your Tests Providing A False Sense of Security?

Brett Cassette — Wed, 20 Feb 2019 21:17:06 +0000

This article is part of my Testing from First Principles series. If you enjoyed this series, stay tuned for practical testing advice on my Cypress End-To-End Testing course on egghead.io

Tests as Checklists

I think of tests much in the way that Atul Gawande describes surgeons' checklists in The Checklist Manifesto.

Our jobs are complex, and we can miss incredibly basic things unless we have a checklist.

But a checklist is executed by a human. It forces us to consider the various complexities and edge cases one by one.

Automated tests are executed by a computer, without manual intervention, and without us being forced to review them.

Which leads to some questions to consider...

When's the last time you looked at your tests?
Do they test only the happy path? Or all edge cases?
Did you mock out some objects to improve test speed? Or is everything tested end-to-end? Do you remember?

Why are you confident these tests will keep your application safe?

When we're confident the "checklist" is correct and complete, we can miss things that would have been blindingly obvious if we thought about the problem ourselves.

If your boss asks, "Is this code safe to ship?" and you reply, "The tests are passing," then you haven't answered the question. You haven't engaged with the process of doing so because it's much easier and requires less accountability to trust in the tests.

Tests can provide security when done right. But when we fail to consistently engage with our tests, that sense of security is undeserved. We have to know what the tests exercise, why, and what's missing.

Is this test case an accurate representation of how users really interact with our website?
Are we truly testing features end-to-end?
Are we using real user data, or imaginary scenarios?

Your tests might be really killer. Or they might be a security blanket when what you need is a shield.

Practical Advice

Testing is great, but if it's the only tooling giving you code confidence, you're playing High Stakes Poker.
End-to-end testing used to be slow and flaky with Selenium, but with Cypress, you can get the security of e2e that's worth the investment.
Cypress enables testing against all levels of the stack (databases, XHR requests and responses, frontend stores, and UI), and doing so will communicate to your teammates what the entire lifecycle should look like. This is particularly helpful for more junior team members, or team members unfamiliar with your product's technology.

This article is part of my Testing from First Principles series. If you enjoyed this series, stay tuned for practical testing advice on my Cypress End-To-End Testing course on egghead.io