DEV Community: Harriet Ayugi

JavaScript Closure Simplified

Harriet Ayugi — Mon, 12 May 2025 20:56:57 +0000

Have you ever wondered how JavaScript functions can "remember" things even after they've finished running? That’s the magic of closures, and today we’ll break it down with a simple use case: building a custom counter function. We’ll touch on key concepts like function factories and state persistence to bring this idea home.

Closures:
In JavaScript, a closure is created when an inner function keeps access to variables defined in its outer function, even after the outer function has returned.

For example, in our counter, a variable count is defined inside makeCounter(). The inner function (the actual counter) uses this variable. Thanks to the closure, the count is not lost when makeCounter() finishes, the counter function still remembers it.

Function Factory: One Function, Many Counters Think of makeCounter() as a factory. Every time you call it, it gives you a brand new counter, like a fresh instance with its own private count. Each counter is completely independent.

State That Sticks(State Persistence) The beauty of closures is state persistence. Since count is part of the closed-over scope, it keeps its value between function calls. That’s what allows the returned function to keep incrementing the same number, step by step.

The key takeaway: even though makeCounter() is finished, the returned function still has access to everything defined inside it. That’s the closure in action, enabling encapsulation, memory, and a clean way to manage state without global variables.

Closures aren’t just cool, they’re powerful. Once you understand them, you’ll start seeing them everywhere in JavaScript. And best of all, they make patterns like private counters, once complex, totally natural.

Evaluation of Microsoft Playwright

Harriet Ayugi — Thu, 04 Mar 2021 12:30:26 +0000

Introduction

Test automation is a way to automate a browser by simulating user actions like clicks. Applications become more complex as they are built on layers and entire networks of sub-systems, including UI and API layers, external databases, networks, and even third-party integrations. So, there is always a need for thorough testing to be done. This ranges from unit testing to end-to-end testing of applications. Test automation is one of the ways to ascertain the stability and the health of applications. That can lead to the success of the application when in production. The general stability of the application doesn't entirely depend on end-to-end testing but it surely helps to detect bugs in applications, among other benefits.

Below are some of the popular test automation frameworks being used;

Playwright maybe the new kid on the block but it's gaining quite a trajectory among software developers and testers.

Project Background

The Playwright evaluation is a result of a need for to check if WebdriverIO is still a good test automation framework compared to some of the best non-Selenium modern test automation frameworks. MediaWiki is implemented in a large number of repositories. So, in order to ensure good code practices across all these repositories, an extensive amount of testing is performed. One of the tests performed is an end-to-end test. WebdriverIO is the current browser automation framework being used for implementing the end-to-end tests. However, with the recent increase in awareness about end-to-end testing, a number of equally competitive non-Selenium solutions have been introduced and one of them is Playwright.

At the time of choosing which automation framework to use in the implementation of the test automation, extensive research was done and an evaluation of WebdriverIO was carried out by Željko Filipin, who is a Senior Engineer in Test at Wikimedia Foundation and also one of my mentors. To verify if WebdriverIO is still a great testing framework for MediaWiki, a number of modern and non-Selenium automation frameworks have been evaluated against WebdriverIO. These evaluations were done by Soham Parekh who was Google Summer of Code 2020 intern and is also one of my mentors and Sim T.H. Tran. These evaluations can be found in the links below;

Cypress Evaluation by Sim T.H. Tran.
Puppeteer Evaluation by Soham Parekh.

So, this brings us to the current framework being evaluated against WebdriverIO, which is Playwright. The evaluations progress involved the following steps;

Configuring and setting up of Wikimedia Core to run on continuous integration, in this case on Github Actions.
Implementation of all MediaWiki Core tests in Playwright.
Running MediaWiki Core tests in WebdriverIO.
Analysis of both WebdriverIO and Playwright tests in terms of speed and stability.

WebdriverIO

WebdriverIO is a test automation framework that allows you to run tests based on the WebDriver protocol and Appium automation technology.

WebdriverIO provides the ability and options to run commands in both asynchronous and synchronous operations. For asynchronous operations, you can use the JavaScript usual async/await, however for synchronous, it can be done through node-fibers. Both of these options have their own benefits and issues which can be found on the WebdriverIO website.

Sample WebdriverIO Code

The code snippet below navigates to wikipedia.org in Chrome and checks if the correct title is being displayed.

const { remote } = require('webdriverio');

(async () => {
 const browser = await remote({
        capabilities: {
            browserName: 'chrome'
        }
  });
  await browser.url('https://www.wikipedia.org/');

  const title = await browser.getTitle();
  expect(title).toHaveTitle('The Free Encyclopedia');

  await browser.deleteSession();
})();

Mocha

The WebdriverIO WDIO runner currently supports Mocha, Jasmine, and Cucumber frameworks and WikiMedia Core test is currently using Mocha framework. Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun.

WebdriverIO provides an adapter for Mocha which can easily be added as @wdio/mocha-framework.

Sample Mocha Code

The code snippet below navigates to wikipedia.org in Chrome and checks if the correct title is being displayed.

const { remote } = require('webdriverio');

describe('Wikipedia home page', async() => {
  const browser = await remote({
        capabilities: {
            browserName: 'chrome'
        }
  });

  it('should display correct page title', async() => {
    await browser.url('https://www.wikipedia.org/');

    expect(browser).toHaveTitle('The Free Encyclopedia');

    await browser.deleteSession();
  });
})();

WebdriverIO Advantages

WebdriverIO offers some great pros such as;

Extendable, adding helper functions, or more complicated sets and combinations of existing commands is simple and really useful.
It's Compatibility nature enables it to run on the WebDriver Protocol for true cross-browser testing as well as Chrome DevTools Protocol for Chromium-based automation using Puppeteer.
Rich feature with huge variety of community plugins that allows you to easily integrate and extend your setup to fulfill your requirements.
Stable features.
Synchronous implementation of asynchronous browser commands.
Excellent API documentation.
Support for modern web and mobile frameworks.

WebdriverIO Disadvantages

WebdriverIO also presents some cons such as;

Additional effort to set up browser driver with selenium-standalone or ChromeDriver especially in v5 and below.
Much slower compared to frameworks like Playwright and Puppeteer.

To explore more WebdriverIO capabilities, you can check out the WebdriverIO and MediaWiki documentation.

Playwright

Playwright is a Node.js library to automate Chromium, Firefox, and WebKit with a single API.

While working with Playwright for the past few months, it has come across as easy to install and setup. The package takes care of installing all the browsers (Chromium, Firefox, and WebKit). Capturing screenshots is an out-of-the-box experience. However, video recording requires separate installation of playwright-video and ffmpeg but they all blend in with Playwright seamlessly.

Sample Playwright Code

The code snippet below navigates to wikipedia.org in Chrome and checks if the correct title is being displayed.

const { chromium } = require('playwright');
const expect = require('expect-playwright');

(async () => {
  let browser, page;
  browser = await chromium.launch();
  page = await browser.newPage();
  await page.goto('https://www.wikipedia.org/');

  const title = await page.$('.localized-slogan');
  await expect(title).toEqualText('The Free Encyclopedia');

  await browser.close();
})();

Jest

Jest is a delightful JavaScript testing framework with a focus on simplicity. Playwright can be integrated into a project in two ways and one of them is by using the jest-playwright which has rich features like:

Multi-browser and device (like iPhones with given screen sizes) support.
jest-dev-server integration which can start your webserver like create-react-app before running the tests.
expect-playwright integration which provides common expect helper functions.

jest-playwright is added to the jest configuration as a preset which makes all the features available to be used at your disposal. It was inspired by jest-puppeteer.

Sample Jest Code

The code snippet below navigates to wikipedia.org in Chrome and checks if the correct title is being displayed.

const { chromium } = require('playwright');

describe('Wikipedia home page', async() => {
  let browser, page;
  browser = await chromium.launch();
  page = await browser.newPage();

  it('should display correct page title', async() => {
  await page.goto('https://www.wikipedia.org/');

  const title = await page.title();
  await expect(title).toBe('The Free Encyclopedia');

  await browser.close();
})

Playwright Advantages

Playwright offers some great pros such as;

Test across all modern browsers with single API to automate Chromium, Firefox and WebKit.
The API can be used in JavaScript & TypeScript, Python, C# and Java.
It's simple to set up.
Stable features.
Bidirectional (events) – automating things like console logs is easy.
Auto-wait for elements to be ready before executing actions (like click, fill).
Intercept network activity for stubbing and mocking network requests.
Seamless integration with Jest.

Playwright Disadvantages

Playwright also presents some cons such as;

It is very new so the APIs are evolving.
Has no support for IE11 or non-browser platforms.
Documentations and community are not as good as the other framework yet.

To explore more on Playwright capability, you can check out the Playwright documentation and my MediaWiki Core fork.

Playwright Vs WebdriverIO

The below table is a comparison between Playwright and WebdriverIO in terms of;

Performance
Developer Experience
Documentation
Ecosystem/Community

Key Factors	Playwright	WebdriverIO
Performance	- Fast - Stable - Reliable	- Slower - Stable - Reliable
Developer Experience	- Simple setup - Javascript-based	- Additional browser driver set up (v5 and below) - No additional browser driver set up (v6+) - Javascript-based
Documentation	- Great documentation - Detailed instructions - Good example projects	- Fairly good documentation - Great example projects
Community	- New framework - Smaller community - Few maintainers	- Larger community - Many maintainers

Statistics

The above data was adopted from npm trends showing WebdriverIO and Playwright downloads. From the above charts, we see that WebdriverIO still trumps Playwright when it comes to popularity among the testing community.

MediaWiki Core Tests

The above visualized chart represents data that was collected by running MediaWiki Core tests in WebdriverIO and Playwright. A total of 10 tests were run using both frameworks on Github Actions platform.

The tests were run 40 times in both frameworks to ascertain stability and reliability. No flakiness and failures were encountered during the tests run. As shown above, there is consistency in time when the tests were run in WebdriverIO and Playwright.

The above chart further shows that Playwright is much faster than WebdriverIO in terms of speed.

Migrating From WebdriverIO

From the various evaluations done with Playwright, there seems to be great potential replacement in the future. Playwright seem to stand out in terms of both speed and stability. However, the question being asked is, is it worth migrating from WebdriverIO to another test automation framework? Let’s look at the advantages and disadvantages of a potential migration.

Advantages

WebdriverIO is JavaScript based and is built over Node.js just like Playwright thus making it easier for developers to stick to the same programming language in the face of a potential switch to Playwright.
The MediaWiki Core test implementation follows the Page Object Pattern, this would make it easy to write Playwright tests using the existing structure.
Playwright has a number of useful features that come with it like the reset helper functions and single API to automate Chromium, Firefox and WebKit, among others. Some of these features are missing in WebdriverIO thus making Playwright a better option for a switch.

Disadvantages

Investment in WebdriverIO tool. Most tests are already written in WebdriverIO. About 30 MediaWiki repositories use it, so migrating from it to another tool would require a great deal of time and manpower.
Update of documentation. Most documentation is already written and has references to WebdriverIO. Updating the documentation would require some time.
WebdriverIO incorporates Puppeteer as second automation driver tool allowing for the extra features which pretty much make up for some of the features that Playwright has, hence no much point in switching to Playwright.

What Next

Refactor existing tests.
Evaluate Puppeteer.

Summary

As of the above statistics and comparison, Playwright is a better alternative tool over WebdriverIO in terms of speed. However, WebdriverIO is a great tool given that it keeps evolving, new and modern features are being added to it and the community is still vibrant and supportive. With the recent release of WebdriverIO v7 which has some great feature update, and the fact that WebdriverIO incorporates a framework like Puppeteer as second automation driver tool makes WebdriverIO a powerful test automation framework. There is also a potential integration with Playwright in the near future. As of the time of the evaluation, there are no plans to switch to a different test automation framework but this could change in the future.

Acknowledgement

The completion of this project wouldn't have been a success without the support of my mentors, Željko Filipin, Vidhi Mody and Soham Parekh. I do appreciate the constant guidance, meetings, advice, code reviews, challenging, pair programmings, to mention but a few, that were offered during the project execution.

References

Puppeteer, Selenium, Playwright, Cypress – how to choose? by Benjamin Gruenbaum.
Using Jest with Playwright by Max Schmitt.
State of JS 2020: Testing by Sacha Greif and Raphaël Benitte.
Playwright Community.

What is next.....??

Harriet Ayugi — Sun, 07 Feb 2021 22:53:05 +0000

It has been over two months into my internship at Wikimedia foundations under the Outreachy program. I have written some blog posts about the internship here. I'm really excited about the journey so far. There has been a lot of learning, building stuff, and experiences. Before starting to contribute to open source projects, I had the imposter syndrome whereby, I felt like because I didn't know much, I would fail and be probably be ousted but to my surprise, open-source communities are one of the most patient and tolerant communities I have ever come across! My mentors have been so supportive during this journey and I'm really grateful for that.

The internship will be ending in a few weeks and the question that I'm asking myself right now is, what is next? I have thought about this and I have come to the conclusion that I need to get a job or internship as I continue to make contributions to Wikimedia foundations after the internship. I will be taking the following steps when the internship ended;

Go on a vacation for a week or two
Update my Resume
Update my Linkedin
Apply for jobs
Network by joining active community groups or job opportunities mailing groups.

During my internship, most of the work I have been doing is related to test automation and a bit of continuous integration. Prior to the internship, I have had experience building frontend applications using Javascript/ReactJs. Below are some of the experiences and skills I have gained during the internship;

Test automation using Microsoft playwright
Continuous integration using Github actions With these skills and experiences, I'm open to remote roles with Frontend and Test automation full-time/part-time job opportunities or internships.

Moving forward, I do plan to continue learning more about test automation and test automation frameworks like WebdriverIO, Puppeteer, and Cypress.

Internship Project Progress

Harriet Ayugi — Tue, 19 Jan 2021 13:19:20 +0000

It has been about one and a half months into the internship with Wikimedia. I have written a number of blog posts about my journey and the project I'm currently working on. Just a little a bit of a refresher about the project I'm working on, it's Evaluation of Microsoft Playwright as a replacement for the Wikimedia browser automation. Before I had started working on the project back in December, there were some estimated project goals and deadlines that I had set such as;

implementation of existing tests across moderately sized repo's in Microsoft Playwright
Introduce video recording and screenshots of tests
Benchmark Playwright against Puppeteer (using the previous implementation) and WebdriverIO.

However, when the internship started, I and my mentors came up with more clear and defined project milestones such as;

Dec 1 to Dec 15- Run Playwright tests in Continous Integration(CI)
Dec 15 to Feb 01- Implement MediaWiki/core tests in Playwright
Feb 02 to March 01- Benchmark Playwright against WebdriverIO (and Puppeteer).

From the time the internship commenced, I started by setting up the project such as forking and cloning the MediaWiki/core repository from Github since it was decided that the evaluation of the Playwright would be done on Github instead of Gerrit to minimize some CI related issues. The first milestone(Run Playwright tests in CI) involves a number of tasks such as;

Setting up CI pipeline
Configuring Nodejs, Docker, test to run in CI
Configuring and Setting up Playwright, running MediaWiki-docker in CI, running sample Playwright test in CI, etc.

The above tasks were estimated to take two weeks, however, it took me about a month to accomplish the first milestone, some of the reasons for the delay are;

I started working with Travis CI as the CI tool for the project, however, within a week into the implementation, we realized that Travis CI doesn't store artifacts out of the box, it requires additional setup and configurations such as using AWS, Github pages, or any other external services to store artifacts. So, to simplify the workflow and configurations, we decided to use Github actions as the CI pipeline for the project. Configuring and setting up Github actions took me about a week.
Configuring and Setting up Playwright, running MediaWiki-docker in CI, running sample Playwright test in CI took me about two weeks, there were issues like running MediaWiki-docker successfully too.

The general setup of the project was more complicated than I had anticipated but with much help from the mentors, whereby we could have several meetings a day and pair programming to resolve issues. I have managed to complete the first milestone even though it has taken me more time than expected.

I'm currently working on the implementation of the second milestone(Implement MediaWiki/core tests in Playwright). This milestone involves writing and implementing different MediaWiki/core test suites in Playwright. There is so far tremendous progress with writing the tests as the overall project goals and expectations become much clearer. I'm working towards ensuring that all the tests are written within a week and start working on the implementation of the third milestone(Benchmark Playwright against WebdriverIO (and Puppeteer)), which should take me about two weeks.

Looking back at how far I have come with working on the project, there are a couple of things I think I would have done differently;

Do prior research on Continuous integration tools that would suit the need of the project instead of just settling for a tool that I was familiar with(Travis CI).
Perhaps asked for more help from my mentors during the setup and configurations.

With all the changes and challenges, I have also learned quite a valuable lesson about project estimations, that it's good to set deadlines and milestones, they help in achieving the end goal of the project but they are also expected to change as implementation begins and progresses.

Evaluation of Microsoft Playwright framework

Harriet Ayugi — Tue, 05 Jan 2021 08:28:05 +0000

It has been over a month since I started my internship with Wikimedia under the outreachy program. Wikimedia is a global movement whose mission is to bring free educational content to the world and strives to bring about a world in which every single human being can freely share in the sum of all knowledge. Wikimedia is the platform that runs Wikipedia and it's sister projects. Wikimedia constitutes a global community of educators, learners, librarians, software developers, to mention but a few. The project that I'm working on is called MediaWiki which is used to collect and organize knowledge and make it available to people. It's implemented in PHP and powers a number of websites. I'm specifically working on the Evaluation of Microsoft Playwright as a replacement for the Wikimedia browser automation project.

Project context
Wikimedia supports a large number of repositories as well as extensions. In order to ensure good code practices across all these repositories, an extensive amount of testing is performed and one of the tests performed is an end to end test. WebdriverIO is the current browser automation framework being used for implementing end to end test. However, with the recent increase in awareness about an end to end testing, a number of equally competitive non-selenium solutions have been introduced and one of them is Microsoft Playwright. So, the goal of the project is to evaluate Microsoft Playwright against WebdriverIO as a potential replacement for the Wikimedia browser automation framework.

Automated browser testing is a suite of tools to author, manage and run tests against browsers across platforms. Some of the common browser automation tools used are Selenium, Cypress, Puppeteer, and Microsoft Playwright. Microsoft Playwright is the newest addition to the list of the framework, it's an open-source, JavaScript-based, cross-browser automation library for end-to-end testing. Playwright provides a single API to automate web applications across three major browser engines; Chromium, Firefox, and, WebKit which makes it different from the other Automated browser frameworks.

There has been a lot of learning new things during this process so far. I have implemented unit test before, however, it is my first time implementing automated browser testing and there has been a lot of learning and implementation of new things such as; the different browser automation frameworks, how to use Github actions as continuous integration(CI) pipeline, learn about Microsoft Playwright and its implementation to mention but a few. This is both a challenging and exciting project for me to work on and hopefully, the evaluation of Microsoft Playwright will turn out to be successful and become the automation tool for Wikimedia.

Struggle, the road to growth

Harriet Ayugi — Thu, 24 Dec 2020 08:39:05 +0000

It has been more than 3 weeks into my Outreachy internship with Wikimedia foundations. The internship started well and the project that I'm working on is about evaluating Microsoft playwright as a possible replacement to the current automation testing framework being used. Week one was mostly about setting up the Wikimedia core by forking and cloning the Wikimedia core repository from Github. In order to simplify continuous integration, we are using Github as our code hosting platform to evaluate playwright instead of using Gerrit. The setup involved the following steps;

Forking the Wikimedia repository
Cloning the repository, setting up and running it on my local machine
Connecting my forked with upstream
Configuring CI.

Week two followed up with more configurations and installations of dependencies, configuring CI to work with docker, run test, etc. The configurations and setup continued into week 3, I continued with setting up and configuring Playwright, jest, etc. On the third week, my mentors and I realized that Travis CI might not be the best CI tool to use for continuous integration in evaluating playwright because of a couple of reasons;

Travis CI doesn't store artifacts out of the box, it requires additional setup and configurations such as using AWS, Github pages, or any other external services to store artifacts.
travis-ci.org is shutting down soon and will be migrating to travis-ci.com. So, to simplify the workflow and configurations, we decided to use Github actions as the CI pipeline for the project.

The change to using Github actions meant that I had to abandon Travis CI and move to Github actions whereby, I had to take a little bit of time to learn and get familiar with how Github actions work. Moving to Github actions has been a great idea because I'm seeing the tests and linter run much faster and we are now able to store artifacts by just adding minimal configurations. This has come with its own challenges like learning how to use GitHub actions and falling behind the project milestones and deadlines. I have struggled with a number of issues like;

How to work with the forked repository, updating upstream with the forked repo. There was a time when I updated the upstream with my master and immediately rebased with a feature branch, this added all the commits from upstream and messed up all my commits, we had to abandon the pull request and created a new branch. I learned from this. It has been a bit of a challenge and learning when it comes to working with a forked repo but with the help of my mentors, I'm getting past this.
I have had several issues with setting up and configuring jest with Microsoft playwright, but my mentors have been there to help unblock me.

All in all, I have learned so much so far within this short time and have been able to make progress with the project. I'm also putting in extra effort to ensure that I hit the project milestones in time. My mentors have been very helpful in pointing me in the right direction whenever I get stuck or have issues with the tasks I'm working on.

To dream a dream. My outreachy Journey

Harriet Ayugi — Tue, 01 Dec 2020 13:23:03 +0000

The year 2020 has been a year of massive change in the entire world, there are mixed feelings of loss, confusion among others, but all in all, there is always hope that keeps us moving forward. I must say that being accepted as an Outreachy intern has been that ray of light at the end of the tunnel that I needed to end the year and begin the new year. Outreachy is a paid, remote internship program with the goal to support people from groups underrepresented in tech. Starting my career in the field of software engineering has been a journey of hard work, persistence, and seizing every opportunity since where I come from such opportunities are rare and the support for women's engagement in technology is quite low.

My journey into being accepted as an outreachy intern started when I submitted my application about 3 months ago, the whole
Outreachy application takes approximately 3 months. During the application process, I got the opportunity to contribute to open-source projects, which is one of the requirements of the initial application process. Contributing to open-source projects is something new to me, I had never contributed to any open-source project before even though I have been coding for a while now. This is a completely new path for me in my career as a Software Engineer and it's one I'm truly excited to embark on, though a bit scary but I know that great things will come out of it!.

As part of the outreachy program, I got accepted as an intern at Wikimedia as a Software Developer intern, which will last for 3 months, and December 1st marks my day as an official Wikimedia intern. Excited!!. Wikimedia is a global movement whose mission is to bring free educational content to the world. One of the reasons why I'm passionate about technology is the impact it makes in the lives of people and in the world at large, the kind of impact I see Wikimedia making by providing free educational content. I'm thrilled to be working with such a community of great and smart minded people and continue to make an impact by building and contributing to open source. I have the privilege to be mentored by Vidhi Mody, Željko Filipin, and Soham Parekh whom I look forward to learning from and collaborating with.

Keep an eye on this corner for more blog posts and adventure! I will be blogging about my experience with the new technology I will be using, Outreachy, internship experience at Wikimedia, Open source projects, to mention but a few.