In this post, I will show you some advanced usage patterns for working with Playwright in order to take a screenshot of a specific element and modify the contents of the image, either before taking the screenshot or after, using image preprocessing tools.
That is the question. Whether âtis nobler in the mind to suffer the slings and arrows of outrageous test coverage, or to take arms against a sea of bugsâŠ
Debbie OâBrien âSenior Program Manager at Microsoftâ joins Amal & Nick for a deep-dive on Playwright, an automation library for cross-browser end-to-end testing. Along the way, we learn why Microsoft decided to fork Puppeteer, Playwrightâs unique value proposition, cool features like auto-waiting & the trace viewer, how it compares to Cypress & a lot more.
For web automation/testing, Selenium has been the de facto âstandardâ since forever. Itâs simple to get started with and supports almost every programming language.
My problem with it has been: Itâs good enough, but nothing more. It doesnât work that well with modern, Javascript framework heavy sites (Angular, React etc). Iâm not saying it doesnât workâ just not too well.
I know a lot of people who use Selenium, but I donât know a lot of people who enjoy using Selenium. (Thatâs no knock on the Selenium team. They solved a hard problem for lots of devs over the course of many years. Huge impact!) Playwright on the other handâŠ
Hillel Wayne:
I practice âweak TDDâ, which just means âwriting tests before code, in short feedback cyclesâ. This is sometimes derogatively referred to as âtest-firstâ. Strong TDD follows a much stricter âred-green-refactorâ cycleâŠ
Turns out I also practice âweak TDDâ most of the time, but I didnât know there was a (derogatory) term for it. In this post, Hillel lays out why he does weak TDD and why he doesnât do strong TDD. Oh, and stick around to the end to learn why he thinks TDD hasnât conquered the worldâŠ
Dr. Gleb Bahmutov returns to the party for a wide-ranging discussion on open source, end-to-end testing, Cypress, and more. Amal, Divya & Chris host.
OSS developer Jessica Sachs joins Jerod & Kball to discuss re-launching and maintaining Faker.js after it was abandoned last January, Component Driven Development & Neopets!
Philip Walton:
While most teams I talk to would love to be able to run A/B tests to accurately assess the performance impact of certain changes, the problem is pretty much every popular A/B testing tool on the market has such a negative impact on load performance that theyâre essentially unusable for this purpose.
If youâre just trying to determine which of two marketing headlines converts better, then perhaps this performance difference isnât so bad. But if youâre wanting to run an A/B test to determine whether inlining your CSS in the
<head>of your pages will improve your FCP, well, those popular A/B testing tools are just not going to cut it.
He goes on to describe his process for running performant A/B tests on his static site using Cloudflare workers to swap in/out his experiments.
Christopher Meiklejohn has been working for two years on developing an automated resilience testing tool called Filibuster and was able to test it out at DoorDash during his research internship:
Access to DoorDashâs real-world industrial microservice application was extremely valuable both to ensure that Filibusterâs design matches how microservice applications are developed today and to influence future features that I would not have identified in a lab setting.
The results were pretty good! Maybe we wonât need chaos monkeys as tools like Filibuster advance?
In short, Filibuster can identify many of the technical resilience issues that exist in applications earlier, at the time of development, without testing in production as required in more traditional chaos engineering techniques.
Victor Engmark thinks we should start test names with âshouldâ for a handful of reasons, hereâs a few:
- It removes redundancy, because the function name should already be in the call stack.
- It is falsifiable, a person reviewing the test can decide to which degree the name agrees with the actual test.
- It encourages testing one property of the function per test
I donât disagree, but I like to take it a step further: Let the âshouldâ be implied by the rest of the test name.
Instead of: should replace children when updating instance
I prefer: replaces children when updating instances
Instead of: should apply discount when total cost exceeds 100 dollars
I prefer: applies discount when total cost exceeds 100 dollars
Most of Victorâs reasons for using âshouldâ still apply with this format, but itâs less verbose and more accurately describes the software working as expected when the tests pass.
Good for them (and us)! But what does that mean in practice?
Over the next few months, weâll be completing the OpenJS Foundationâs incubation program checklist, including transferring the Jest domain, repo, website, and other assets to OpenJS. Weâll also be updating the code of conduct and contributor license agreement.
Additionally, as part of this move, we will be publishing a project charter and creating new governance policies that will document the process for gaining commit access, as well as our leadership selection process.
Next up: React?! A guy can dreamâŠ
Pia Wiedermayer, Lead QA at ZĂŒhlke, is talking with Gerhard today about software quality. If the name sounds familiar, check out episode 28. Thank you Romano for the introduction đđ»
Do you remember the last time that you used an app, whether it was in the browser or on your mobile, and everything just worked? What about that intuitive feel, snappiness and you achieving the task that you intended to without feeling that you are fighting tech? Experiences like those take a lot of effort across multiple disciplines. They are designed, built and maintained over long periods of time. It all starts with people like Pia that really care about quality. Itâs so much more than just automated testingâŠ
I love articles like this one because I was ready to disagree with it going in, but it was so well-reasoned and articulate that I ended up agreeing with most everything the author proposes.
This hit my radar a few times in the past year â this week, and then most recently a few months back when we had Richard Hipp on The Changelog (again) â but, I didnât post it to the newsfeed.
Hereâs whatâs interesting about the SQLite test suite â itâs their secret sauceâŠthe sustaining enablement of building a support business around SQLite. Hereâs a direct quote from Richard Hipp in that episode.
Originally we thought we were gonna sell this and make money from it, and thatâs how we were gonna support ongoing development. That didnât really play out, nobody ever bought it. It does sort of become our business value, our intellectual property. I mean, you can take the SQLite code and fork it and start your own thingâŠbut you donât have the full test suite. Youâve got a lot of tests, but not all of them. So weâve got a little bit of advantage over you there.
Click here to play that episode from this quote.
Jacob Kaplan-Moss, who has been writing a lot about good interview questions and how to hire well:
Work sample tests are an exercise, a simulation, a small slice of real day-to-day work that we ask candidates to perform. Theyâre practical, hands-on, and very close or even identical to actual tasks the person would perform if hired. Theyâre also small, constrained, and simplified enough to be fair to include in a job selection process.
To give you a more concrete idea of what Iâm talking about, here are several examples of work sample tests Iâve usedâŠ
And just in case you think heâs prescribing whiteboardingâŠ
However, work sample tests are also a minefield: the space is littered with silly practices like whiteboarding, FizzBuzz, Leetcode, and âreverse a linked listâ-style bullshit. The point of this series is to separate these silly practices from the good ones and to give you a framework and several examples to use in your hiring rounds.
Property-based tests give us more confidence in our code. Theyâre great at catching edge-cases we may not have thought of otherwise. But this confidence comes at a cost. Property tests take more effort to write. They force you to think hard about what the code is doing, and what its expected behaviour should be. Itâs hard work. And on top of that, running 100+ tests is always going to take longer than running 3â5 example-based tests. This cost is real, and it raises the question:
How do we keep ourselves from over-specifying or writing unnecessary tests?
Property-based testing helps us write better tests, with less code, and greater coverage. This leads to more confidence in our code, and fewer bugs in our applications. But, as always, thereâs a price. Property tests take more effort to write, and they take longer to run. But theyâre worth it.
Recently I discovered additional reasons to write tests for my code! Besides obvious and well-known ones described in books and many blog posts, I realized that the process of writing tests has also psychological effects for me. These effects are especially helpful in cases of hotfixes that need to be deployed as soon as possible.
This week Gerhard is joined by Justin Searls, Test Double co-founder and CTO. Also a đ magnet. They talk about how to deal with the pressure of shipping faster, why you should optimize for smoothness not speed, and why focusing on consistency is key. Understanding the real why behind what you do is also important. Thereâs a lot more to it, as its a nuanced and complex discussion, and well worth your time.
Expect a decade of learnings compressed into one hour, as well as disagreements on some ops and infrastructure topics â all good fun. In the show notes, you will find Gerhardâs favorite conference talks Justin gave a few years back.
The top 1% of companies spend thousands of hours building their own A/B testing platforms in-house. The other 99% are left paying for expensive 3rd party SaaS tools or hacking together unmaintained open source libraries.
Growth Book gives you the flexibility and power of a fully-featured in-house A/B testing platform without needing to build it yourself.
Rainer Hahnekamp:
On 24th April 2021, Angular announced the deprecation of their E2E testing tool protractor. It was unclear if there will be a successor or if Angular delegates this to its users. In this article, I will provide a short overview over the differences between the various E2E frameworks, and argue why you should use Cypress.
Iâve heard nothing but high praise of Cypress and thoroughly enjoyed our conversation with Gleb Bahmutov when he joined us on JS Party.
By adding visual elements to your tests, you can gain more options to add meaningful ways in maintaining a high level of quality for your app. Colby Fayock explains how.
This article pairs nicely with what Angie Jones had to say about visual testing on Our recent JS Party episode.
Fuzzing is coming to the standard library. We speak to Katie Hockman and Jay Conrod who were part of the team responsible for designing and implementing it. We dig into the details, hear some best practices, where fuzzing can help your code, and learn more about how it works.
