Playing with Playwright

Playwright is a new browser automation library from Microsoft:

Playwright is a Node library to automate the Chromium, WebKit and Firefox browsers with a single API. It enables cross-browser web automation that is ever-green, capable, reliable and fast.

https://github.com/microsoft/playwright

I’m a big fan of Puppeteer, so this section in their FAQ stood out to me:

Puppeteer is a Node library which provides a high-level API to control Chrome or Chromium over the DevTools Protocol. Puppeteer project is active and is maintained by Google.

We are the same team that originally built Puppeteer at Google, but has since then moved on. Puppeteer proved that there is a lot of interest in the new generation of ever-green, capable and reliable automation drivers. With Playwright, we’d like to take it one step further and offer the same functionality for all the popular rendering engines. We’d like to see Playwright vendor-neutral and shared governed.

https://github.com/microsoft/playwright#q-how-does-playwright-relate-to-puppeteer

Playwright uses similar concepts to Puppeteer:

“Due to the similarity of the concepts and the APIs, migration between the two should be a mechanical task.”

https://github.com/microsoft/playwright#q-how-does-playwright-relate-to-puppeteer

Luckily I have a demo test suite written in Puppeteer which I have cloned and converted to use Playwright to see how it works, and compares.

Here are my thoughts:

I really, really like the BrowserContext concept

In Puppeteer, and WebDriverJs, you have Browsers and Pages. Each Page in a Browser share the state across the Browser, so to create isolated tests using the same Browser (to avoid the inefficiencies of spawning a Browser per test) you need custom code to delete all cookies and local storage between tests. Playwright solves this with the BrowserContext object which is a new incognito window where its pages are created: each test can use the same browser but a different BrowserContext. Super cool 👌

It automatically waits to click, and supports xpath expressions

Playwright automatically waits for elements to be available and visible before clicking, by default, and also has the same API for xpath expressions, which means this Puppeteer code:

await page.goto( `${ config.get( 'baseURL' )}` );
await page.waitForXPath( '//span[contains(., "Scissors")]' );
const elements = await page.$x( '//span[contains(., "Scissors")]' );
await elements[0].click();
await page.waitForXPath( '//div[contains(., "Scissors clicked!")]' );

becomes a lot cleaner:

await page.goto( `${ config.get( 'baseURL' )}` );
await page.click( '//span[contains(., "Scissors")]' );
await page.waitFor( '//div[contains(., "Scissors clicked!")]' );

It supports three “browsers” but not as you know them

Q: Does Playwright support new Microsoft Edge?

The new Microsoft Edge browser is based on Chromium, so Playwright supports it.

https://github.com/microsoft/playwright#q-does-playwright-support-new-microsoft-edge

Playwright supports three “browsers” but not as you know them. I’d say it supports three rendering engines (Chromium, WebKit & Gecko) rather than Browsers as you can only use the (somewhat modified) browsers that come bundled with Playwright over using an already installed browser on your operating system (like Selenium does). This makes it easier to ensure consistency of test runs since the library is bundled with the browsers, but there are some risks your tests could pass on the bundled browsers but fail on “real” browsers. I would say that the claim it supports running on Microsoft Edge is a little misleading.

I’m unsure of CircleCI Support for WebKit and Firefox

I was able to get my tests running against Chromium on CircleCI using the same configuration as Puppeteer, however I couldn’t get the WebKit or Firefox tests to run on CircleCI even when having the default CircleCI browsers installed. I didn’t want to invest the time, but it is probably due to some headless Linux dependencies missing which could be solved in the project config.

Conclusion

If the only thing Playwright did better than Puppeteer was also supporting WebKit and Gecko then I wouldn’t suggest using it over Puppeteer, since Puppeteer is closely aligned with Chromium, and I’m going to run my tests solely in Chrome/Chromium anyway. I don’t believe in running the same e2e tests in multiple browsers: the maintenance overhead outweighs the benefits in my experience.

However, Playwright offers a much nicer BrowserContext concept, and the xpath support is much nicer (although I rarely use xpath expressions anyway).

If anything I am hoping Puppeteer adds support for BrowserContexts – I’ve raised a feature request here so feel free to comment on it if you think it would be a good idea.

All the sample code is available here: https://github.com/alisterscott/playwright-demo

Moving towards a quarterly team story wall

One of the key facets of effective software delivery is continuous improvement to team practices.

The reason I believe physical team walls are so effective in continuous team improvement is that they both reflect good team practices, and drive good team practices. That is, our wall both displays how we’re working, and improves how we work.

If your team is improving how you’re doing things then chances are your wall will look different to how it looked six months ago.

In September I shared how we were using our story wall to display dependencies between tasks for more complex pieces of work.

Our team wall as at September 2019

We’ve since made some improvements to the wall that has continued to improve our effectiveness as a team.

We work in quarterly planning cycles, fortnightly sprints towards our goals, and frequent software releases (once or twice a day typically).

The nice thing about our quarterly planning cycles is that we can neatly fit six sprints within a quarter (12 weeks).

Since the wall represents what we’re doing, and we have this quarterly focus, we thought it would be a good idea to represent the full quarter on our wall. This means our wall currently looks something like:

Quarterly wall

If you zoomed into a single sprint it looks like:

Zoomed into one sprint

Some of the important aspects of the design include:

  1. We put colour coded epics across the top of our board that roughly show when we plan to start each epic. These may not always start at the beginning of a sprint as each epic doesn’t always fit within a sprint and we don’t wait for a new sprint to start a new epic.
  2. Task card colours match the epic to which they belong, except for white cards which are tasks unrelated to an epic – for example tech debt, or a production fix.
  3. Each task card is exactly three columns wide – this is because we try to keep our cycle time, that is the time it takes to pick up a task and merge/release it, to about 3 work days, and each column is one work day. If we find a task is taking much longer than 3 work days it’s a good indication it hasn’t been broken down enough, if it’s much quicker than that we may be creating unnecessary overhead. The benefit of this is more consistent planning, and also effort tracking as we can see at a glance roughly how much effort an epic was by seeing the coloured tickets.
  4. Tasks have a FE/BE label, a JIRA reference, a person who is working on it and one or two stickers representing status.
  5. We continued our status dots – blue for in progress, a smaller yellow sticker to indicate in review, blue and yellow makes a green sticker which is complete. We also use red for blocked tasks, and have added a new sticker which is a purple/pink colour which a black star which indicates this is a tech debt related task.
  6. We move the pink ribbon along each day so it shows us visually where we are at in the sprint/quarter.
  7. We have rows for both team leave, and milestones such as when we enabled a new feature, and also public holidays and team events.
  8. We continue to have our sprint goals and action items displayed clearly at the top of the wall so we can refer back to these during our daily stand up meeting during the sprint to check in on how we’re going.
  9. One extra thing we’ve recently started doing which isn’t represented in the diagram above is when a sprint is complete we shift the cards to the bottom of the wall (in the same columns) so we have a clear future focus, whilst still having a historical view.

We’ve found continually improving our wall represents how our practices have improved and will continue to make improvements as we go. I have no idea how it will look in six months time.

How have you adapted a typical agile wall for your team? How different does it look today than six months ago?

The future of work? An essay.

“The most exciting breakthroughs of the 21st century will not occur because of technology but because of an expanding concept of what it means to be human”

John Naisbitt – Megatrends
New Yorker Cartoon

Introduction

There is a lot of reading available about distributed and remote ways of working but a lot of this is written from the perspective of an employer (Basecamp, Automattic etc) and the benefits it can provide to those employers. Things like gaining access to a global talent pool, more productive employees, workforce diversity, lower office costs, more dedicated staff, and broader timezone coverage.

Remote was an early manifesto for distributed work from the perspective of founders, and highlighted the value the practice provides to open-minded employers”

Working Smaller, Slower, and Smarter

I haven’t been able to find much material that’s written purely from the perspective of an employee that provides a balanced view of distributed and remote ways of working. This essay aims to provide an employee’s perspective of how remote and distributed ways of working compares to traditional office based roles.

Continue reading “The future of work? An essay.”

GitHub & Bitbucket

We use Git on Bitbucket in my current role, and I didn’t realise how much I liked using GitHub until I started using Bitbucket on a regular basis to commit and test code changes.

The biggest difference is how these systems handle squashed commits into a master branch.

With Bitbucket you can do the usual approach of multiple commits on a branch/pull request:

When you go to merge this to master, you can choose squash commits:

which a nice way to make a cleaner commit history on the master branch:

However if you look at the branch/PR now that it is merged you will notice you’ve lost all commit history! 😿

This has been super frustrating for helping us diagnose what went wrong during the development of a change where an issue was introduced.

Comparing this same workflow to GitHub, you can see that you can see individual commits against a branch, and squash these into master:

After merging you can still see the full commit history on the PR and branch:

and it is squashed on the master commit history:

Has anyone else noticed this with Bitbucket? Any known workarounds to keep commit history on branches/PRs?

Now, Next, Later, Never (improving MoSCoW)

Our team sets quarterly objectives, which we break down into requirements spread across fortnightly sprints. As the paradev on my team I work closely with our product owner to write and prioritise these requirements.

We originally started using the MoSCoW method to prioritize our requirements:

The term MoSCoW itself is an acronym derived from the first letter of each of four prioritization categories (Must have, Should have, Could have, and Won’t have

Wikipedia

We quickly started noticing that the terminology (Must have, Should have, Could have, Won’t have) didn’t really work well in our context and how we were thinking, and this caused a lot of friction in how we were prioritizing, and adoption by the team. It didn’t feel natural to classify things as must, should, could, won’t as it didn’t directly correlate into what we should be working on.

Over a few sessions we came up with our own groupings for our requirements based upon when we would like to see them in our product: Now, Next, Later, Never. We’ve continued to use these four terms and we’ve found they have been very well adopted by the team as it’s very natural for us to think in these groupings.

The biggest benefit of using Now, Next, Later, Never is they naturally translate into our product roadmap and sprint planning.

I did some research in writing this post and found Now, Next, Later as a thing from ThoughtWorks back in 2012, but I couldn’t find any links that included the Never grouping as well which we’ve found very useful to call out what we agree that we won’t be doing.

How do you go about prioritizing your requirements?

Questions with a Consolee

When I worked at ThoughtWorks they had this thing called The Interview where every so often Ryan Boucher would publish an interview with a co-worker. The thing I really liked about it was that the person talking was only revealed at the very end.

I’ve stolen the idea and implemented it with modified questions and a portrait photo in my current workplace: Console.


How do you manage to stay on top of things?

Principally, I:

1. I write out lots and lots and lots of lists so that my mind is free to begin thinking clearly.

2. I accept that some days I’ll produce perfect work right out of the gate, and others I’ll be stuck polishing turds. Know what kind of day it is and roll with it.

What skill are you interested in learning next?

I want to get better at cinematography and special effects editing.

What do you love about your current role?

I love that I get to regularly push myself to my creative limits, and that my work shapes people’s experience of Console in myriad subtle ways.

What would you put on a billboard?

Everything counts. Yes, even that.

How do you go about leaving your work brain at work?

It takes me about 40 mins to walk home from work, and 15 mins to bus. I walk, and process the day as I go. It helps me be way more present when I get home.

What is an unusual habit or absurd thing you love?

I can’t go anywhere without a box of Eclipse spearmint sugarfree mints, and I mean anywhere: including to bed. I don’t necessarily use them, I just have a mental thing where I have to have them there NO MATTER WHAT. When I travel, I’ll bring about 2-3 packets for every week I plan to be away. I once traveled for 9 months straight, and I brought maybe 3 cartons (so 24 boxes) with me, and when I ran out there was no decent substitution. It was pretty much the first thing I bought at the airport when I came home >_>

Here’s a pic of my beloved when I was in a state of withdrawal in Canada

What have you changed your mind about?

Dungeons and dragons. I thought it was for nerds. Turns out, I’m a nerd.

When you feel overwhelmed or unfocused what do you do?

My eyes go completely black and people look at me with fear in their eyes. [This is a joke but it is also kind of true. I have a panic face that unnerves my colleagues.] More seriously, I do a lap of the block, sit and write another list, and then just start somewhere—anywhere.

How do you go about making the world a better place?

I try to make the people around me feel special and loved. Whether it’s Console Academy Awards, excessive quantities of fairy lights, glitter bombs or unexpected treats, I’m always looking for ways to make people feel like there’s a little bit of magic in the world.

What question do you wish people would ask you?

What do you love about marketing? I think everyone either has their own idea about what marketing is, or they have ‘a marketing idea’. But there’s so much art and science and theory and creativity and hard bloody yakka to be good at marketing, and I think people have written it off as neither particularly prestigious nor difficult to do well. It’s not a noble profession, but it’s super interesting!

… Maybe that’s why people don’t ask me about it. They know I’ll talk their ear off.

Who are you?

Continue reading “Questions with a Consolee”

Accessibility is good for everyone

It’s great to see the recent changes to Automattic’s long-term hiring processes based upon a user research study into how their approach to tech hiring resonates with women and non-binary folks:

In May, Automattic’s engineering hiring team launched a user research study to better understand how our approach to tech hiring resonates with women and non-binary folks who may experience similar gender discrimination in the workplace and are experienced developers.

What changes did we make?

  • Existing work and life commitments mean that it is important to know the details of the hiring process at the outset: we have published a public page that clearly outlines our hiring process so that people have a concrete understanding of the expectations.
  • We removed all the little games from our job posting page. We were trying to test people’s attention to the job posting and filter out unmotivated candidates; it turned out we were also putting people off who we want to apply.
  • We removed all the language that emphasized that hiring is a competitive process -for instance, removing language about application volume.

Whilst I don’t fit into their target audience for this study, if these changes had been implemented earlier I would have personally benefited from these, instead of being disheartened about waiting for 4 years for a response to a job application that never came (I did eventually work up the courage to apply again at which time I was successful).

This example shows that making your recruitment processes more clear and accessible makes it better for everyone, not just those who experience discrimination – much like web accessibility benefits everyone, regardless of ability.