A Case for Tests

By:

Last Updated: December 20, 2024 @ 4:01pm

Playwright Typescript

Due to the nature of our work, it is not often that we need to really work with the Test-Driven Development (TDD) methodology, but when we do, Playwright is the tool of choice. Here’s why you might want to write tests before you write the rest of your code.

More on Playwright

A computer can do it faster

Although writing tests can seem like a chore, as has been written many times before, TDD can save your bacon, and you’re doing the heavy lifting of thinking through most of the logic of the app by writing tests.

Since Playwright is “end-to-end”, let’s look at a sample flow of what tests might look like (and how they would save you time).

Maintain Fidelity While Refactoring

In 2024 we went through a process of cleaning up the Choctaw Nation’s stylesheet and bringing things like colors, spacing, font sizes, etc, in line. Part of that refactor was improving how the Services’s “Additional Information” <aside> functions.

Previously, if less than 3 columns were needed, the site would render all three column spaces even if the content was empty! Thus, it would commonly occur that the aside would look like column-[gap]-column or [gap]-column-column.

Currently, it conditionally renders up to 3 columns with repeated data. These columns are flex items, so they grow and shift according to how many columns there are.

Each time I made a logic change, I’d go through the same steps:

  1. Go to each URL
  2. Confirm the number of columns
  3. Confirm the columns had the correct width
  4. Confirm the nested content looked correct

If I had written tests, I could’ve simply run the tests and never looked back. Instead, I regularly forgot which URLs to look at and also had to change code to handle edge-cases. And this list didn’t even include color changes!

Test Your Javascript / APIs

Playwright is a client-side testing server (meaning it won’t affect PHP at all), so any time you’re doing anything significant with Javascript you probably want to write some tests first.

Some sites that could (and perhaps do) benefit from tests are:

  • Choctaw Nation Veterans Archive (“Submit a Veteran” form)
  • Housing Bid Board (Intertribal API Integration)
  • Casino Countdown (all of the New Year’s Eve logic is handled with Javascript)

Since Playwright overtakes the Browser context, one major benefit it mocking APIs. This means instead of sending test data and deleting it manually, Playwright could handle that and make sure everything was rendered accordingly.

In fact, that’s how the Bid Board site was built

  • I wrote a fetch request to send a sample bid through
  • Playwright sent it
  • Playwright tested that the bid appeared
  • Playwright tested that the Search and Filter fields worked
  • Playwright deleted the bid it sent

Since Playwright is bundled with @wordpress/scripts I could even go a step further with the tests:

  1. A bid was POSTed by Playwright
  2. Playwright would
    1. Login to WordPress
    2. Navigate to the “Bids” tab
    3. Find the submitted bid and open the “edit” view
    4. Check all the ACF fields to make sure all the data was input correctly
  3. Continue with the above list (front end tests)

It was way more thorough than I would’ve been!

See something inaccurate?