DEV Community: Liam Myles

Why You Hate Test Coverage

Liam Myles — Wed, 15 Jan 2025 22:29:06 +0000

I Love Test Coverage

Cards on the table, I love test coverage, it’s one of the few measures you can get in software development that has some tangible meaning. I particularly enjoy opening up the HTML generated coverage reports and seeing little conditional blocks that got missed, or even just finding out that one part of the code is run hundreds of times.

It’s a wealth of information, insight, and a chance for me to find the mistakes I have made clearly pointed out.

Why you Hate it

So, why do so many people hate test coverage? Why do they scoff at the idea of 100% test coverage, and then debate whether it should be 70% or 80% instead?

Quite simply, the answer is Goodhart’s law. Now if you know what that is, hopefully you can see where I’m going with this. However I won’t make you google it, Goodhart’s law states that "When a measure becomes a target, it ceases to be a good measure”

That’s the rub, teams destroy a valuable measuring stick by turning it into a target, or a stick no longer to measure but to beat either a drum or developers who are a little less savvy with writing tests.

And yes for the pedants out there Goodhart is talking about statistics and government policy, but I still think it gets at something human that erodes away the value of what few measurements we have in this world.

Learning to Love Test Coverage Again

You can drop a rock in your measuring jug to make the last of your milk touch the line. But it doesn’t mean your cake will taste better.

Coverage is a measurement, not a target, stop trying to drop rocks or lowering the line. Your tests should build confidence in your software, and enable developers to refactor it.

Let go of those ideas, the only target you should have for test coverage is for it to NOT be a target. This is easily done by ensuring coverage is 100% and spending your time on other aspects of testing.

“But what about X file that can’t be unit tested”, add it to the coverage ignore list. Make an active decision that it doesn’t add value to be tested. Or face the fact, that you should learn how to test it.

Let go of the worldly percentages that are tying you down, reach 100% and transcend into loving test coverage.

Playing With Polygons - The Iceberg Story

Liam Myles — Wed, 22 Jul 2020 17:56:28 +0000

Intro

This is the iceberg story of the ideas and learnings that lead to my Covid-19 Lockdown Project, Playing With Polygons. Which is a React/P5.js app that lets you create gif's like the one below.

(See and share more gifs on twitter @PlayingPolygons twitter page)

So what is "The Iceberg Story"? Well its the idea that what mostly gets shared is just the final hurdle, or the tip of the iceberg. But I think there is also value in sharing the whole story. So this post isn't about what I did during lockdown. Its about how a bug I created in 2014, lead to this project 6 years later.

The Beginning - Cloning

In 2013 I had watched Nerd Cubed play Super Hexagon. And soon after I bought the game myself, which would inspire me to clone it in university for my processing 2 module in 2014.

While the game got me a good grade, it was rather lackluster. Though its role in this story is actually the bug it helped to create during development. Which was a pretty polygonal spiral - similar to the below gif - that stuck in my head for years to come.

The Time Skip - 4 years later

Its now 2018 and I'm in my second year and second job as a web developer. And 4 things converge to push me to explore this bug I kept remembering.

1 - The Motivation

I'm working as a frontend developer, and es6 is starting to gain a lot of traction. Array functions, Class syntax, const and let, all things I want to learn! But my day job was in legacy jQuery, and I had no desire for my skills to stagnate.

2 - The Tool

I had recently discovered Codepen, and all the wonderful creations people post on it. Back in 2018 I didn't know how to do things like create react app, so Codepen was the answer to an IDE that allowed auto reloading.

3 - The Inspirer

At the same time I was also watching The Coding Train - a fantastic YouTube channel - who's host just oozes enthusiasm while creating visually fascinating p5.js/processing projects. Watching him I couldn't help but be inspired to create something in p5.js.

4 - The Commute

On top of all that, I had an hour long train commute every night. Which starts The Coding - on the - Train section of this story, where I slowly convert my old 2014 java processing 2 code into JavaScript p5.js es6 classes one train ride at a time.

The Result

This all came together into a collection of 6 Codepen pens. Each a fork of the last, telling the story - in code - of copying, and then adding to the polygons created in 2014.

The First Attempt - Playing with Polygons Prototype

During the Codepen experiments I shared some screenshots and videos with a friend. His positive responses inspired me to find a way for him to play with settings for the polygons I had created.

At the same time I was also learning react. So it felt like the perfect excuse to refine my react skills and create something interactive.

However, as things tend to go when you don't have the experience, it became a total mess. Only 1 polygon could be controlled, and the UI became so tightly coupled to the canvas that it became impossible to move forward.

And while I do consider this little project a bit of a failure, I still finished it. No matter how bad the project turns out, I will always encourage people to just finish it. Even if you have to change the definition of finished. It will help refine the skill of wrapping up a project, and hopefully help to make it a habit.

An Impactful Failure - Yahtzee Redux

It's now July 2019, and I'm looking for another quick React side project to improve my understanding of hooks. So I turn to recreating a Yahtzee game I made in university.

However, I let features creep in that weren't in the original. And a simple project that seemed manageable without tests and types ballooned in complexity. Leading to a codebase that became increasingly difficult to add to.

My lack of planning ahead of time meant that features didn't mesh well together. And I was constantly refactoring each time I added a new idea.

My lack of tests meant that any logic changes I made resulted in time consuming manual testing. Testing which could have easily been written if I planned for it.

And my lack of types meant that I had to keep data structures in my active memory constantly, slowing me down as I worked in different areas of the project.

In the end I just had to wrap it up and get it to a playable state.

Lessons Learned - Playing with Polygons

This all leads me to 2020, where between April 19th and July 19th I started and finished Playing with Polygons

Which lead to - what I consider - a successful little project. That anyone can use at its playing with polygons gh-page.

In Closing

I wanted to write something that showed the false starts and learnings that go into an idea. No website or app appears out of some magical burst of intellect. They all have a story below the surface that goes much deeper then you would think.

If you have any iceberg stories please do share, I would love to hear them! You can reach out to me in the comments or on my twitter @LiamMyles92

Also if you found any of this interesting please do let me know. The next post I'm working on is a break down of how I built Playing with Polygons. So any encouragement would be a great boon.

Thanks for reading :)

References

Coding Tools/Libraries Mentioned

Codepen
Processing
P5.js
Create React App

Social platforms mentioned

The Coding Train
Nerd Cubed playing super hexagon
Super Hexagon Website
// Detect dark theme var iframe = document.getElementById('tweet-1284533390742450177-166'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1284533390742450177&theme=dark" }

My Mentioned Code

Codepen Collection

LiamMyles / Playing-With-Polygons-Prototype

Just me playing around with an old Idea.

LiamMyles / yahtzee-redux

My first ever JavaScript app was Yahtzee. That was 5 years ago. This is Yahtzee Redux

LiamMyles / playing-with-polygons

My little polygon art app that I have slowly been working towards for years. I hope you enjoy it.

How I TDD an accessible react accordion

Liam Myles — Sun, 16 Jun 2019 20:31:52 +0000

Intro

I have been doing a lot of TDD at work recently, and I got thinking about the best ways to bring TDD into my react workflow.

This isn't going to be a tutorial on the ins and outs, but more about the ways of thinking when working with user interactions.

The component I'm building takes in components and headers and displays them inside an accordion. If you're interested in the final code, or any of the libraries I used, you will find them all at the end :)

How I start

When I'm working with any complex interactions the first place I look is the wai-aria spec. They have tons of examples on common UX patterns, including an example of an accessible accordion.

This spec is the starting point of this entire component TDD cycle. It clearly outlines the way a user should be able to interreact with an accordion, as well as providing a working example.

I like to start with a long list of todo's. All of these todo's might not end up being the final tests, but it helps me think through the problem.

Its also useful for grouping different pieces of work together into clear logically steps. For example, in the todo's below I need to only show 1 component at a time before I can reliably show content for selected header when clicked

    describe("Accordion Component", () => {
      it.todo("should render Accordion with test data")
      it.todo("should show the headings passed")
      it.todo("should only show 1 component at a time")
      it.todo("should show content for selected header when header is clicked")
      it.todo("should contain the 3 different components from the test data")
      it.todo("should focus next focusable element with tab")
      it.todo("should focus previous focusable element with tab")
      describe("when header is focused", () => {
        it.todo("should expand header with space")
        it.todo("should expand header with enter")
        it.todo("should focus next header with down arrow")
        it.todo("should focus previous header with up arrow")
        it.todo("should focus first header with down arrow when on last")
        it.todo("should focus last header with up arrow when on first")
        it.todo("should focus last header with up arrow when on first")
        it.todo("should focus first header when home is pressed")
        it.todo("should focus last header when end is pressed")
      })
    })

With the tests defined, I would love to just start passing them, but I find it important to lay out the HTML in the same sort of planning way. I won't go through this here, but in my code I just followed the aira spec. Broke it all up into react components that made sense, and updated the correct HTML attributes based on the props passed.

It might be valuable for me in the future to write tests around the HTML, I didn't in this exploration. I'm relying on the interactions to fail if the HTML becomes inaccessibility. However, in hindsight, the screen reader potions of the HTML aren't fully protected.

Writing the tests

Why I write the tests first

While its tempting to dive straight into react, its cleaner and can be more time efficient to just write the tests first. I want to describe what I want to create, so I can easily and simply confirm its been created.

I also want to make sure my test fails before I do anything. Anytime I have been in a situation where updating my tests makes them pass, it forces me to break my code in order to trust it. Which just wastes time.

Why I only think about the current test

I find it very tempting to get caught up in the wider solution. However focusing on the final solution will result in a lot of upfront complexity to manage. This is why I try to think about the smallest amount of code to pass the current test. That way the final solution grows with my understanding of the problem.

In this example, I suspected that I would need useReducer to deal with the state. This sent me down a rabbit hole where I ended up wasting a bunch of time just to show 1 internal component.

In the end I took a step back and just created a const array of Booleans. In doing so I reduced the upfront complexity of the problem and broke it down slowly as I kept passing tests. I did end up using useReducer after all, but my implantation was more robust as it grew with my understanding of the problem.

Things I try not to worry about

I try not to worry about testing the same logic over and over again. A test is always useful as long as it provides some new context. There is no need for DRY (Don't Repeat Yourself) in a test.

I also know I wont catch every edge case in my first pass, if a bug happens in the future, just write a new test so it doesn't happen again. You don't have to get everything right in the first pass. Its just a component :)

What I have in the end

So I have done all of these tests, used testing libraries that emulate how a real user would use it. And created some really robust code. I have all my tests passing, and even added some new tests not in my first todo. And this is what I end up with!

A lovely set of passing tests, and a component that has a long way to go before a user can use it. Its still great, Its really only missing CSS, and CSS shouldn't be tested in most cases. CSS is more of an art and harder to define then JS. But with a nice foundation for the interactions it gives more freedom to just add the design onto an accessible feature.

It also helps protect the accessibility of the component and clearly defined the constraints for the design. It won't catch every accessibility error, but at least it will ensure it functions as the aria spec requires.

Gotchas

Anything new is HARD, learning Jest, React-testing-library & jest-dom is a lot to learn upfront. It also forces you to understand the DOM API, so if that's something you aren't 100% up on some things will be confusing.

I had a lot of fun with it though, and I even added typescript into the mix. But its going to make everything take longer, if you're learning them all for the first time. Especially if you're learning it alone. And that's okay!

Also, managing focus in react is a thing to be aware of, its way outside of the scope of what I'm trying to say here. But think about how you're going to manage focus when the component rerenders. Hint, you will need to learn about ref's

Check out these resources!

What I Consider when Writing CSS

Liam Myles — Thu, 04 Apr 2019 23:11:40 +0000

At a high level, all of these considerations break down into two fronts. The Users download and the Developer ergonomics.

For the users download we want to deliver only the CSS necessary for what they are viewing. And for it to be built on clean HTML.

For the Developers ergonomics we want to break CSS down into manageable chunks, create separation on features and allow reusability. And maybe most importantly, we want our CSS solution to scale and allow for growth with the project.

Write only what you need and writing it once

CSS is flexible, and allows you to do so much. But there is danger in the large amount of flexibility afforded by CSS.

When I write CSS I don't want to repeat myself more than I have to. But there is a balancing act between writing specific CSS for a core feature and general CSS for generic features.

The classic example is button styles. Buttons need to be consistent and a Developer should be able to update all buttons in one location. When a button is styled on a per-feature bases this can lead to CSS getting repeated in each feature.

This repetition can also lead to inconsistent button designs as well as problems updating it in the future.

Don't let tools bloat your final CSS

Tools create an abstraction away from your final CSS. Which has greatly helped the developer ergonomics around CSS. Especially when you live in a world of browser prefix's. However this abstraction hides the CSS you're creating.

Sass for example is a popular CSS preprocessor with features like mixin's, variables and loops. But there are times when the distance from CSS can lead to large amounts of repeated CSS with very minimal developer ergonomic gain.

To demonstrate some of the CSS bloat I have seen I put together two examples on SassMister (SassMister being a playground for SASS that compiles it in the browser).

The first example shows mixins causing repeated CSS vs placeholders expanding only the CSS selector. https://www.sassmeister.com/gist/160390ca9b723bbf08f1d000fa2fa2a7

The second shows the each directive adding svg flag backgrounds. Which I have seen cause over 1000 lines of repeated CSS in live Production code. https://www.sassmeister.com/gist/160390ca9b723bbf08f1d000fa2fa2a7

FYI: If the CSS doesn't load, just put a space into the SASS terminal.

Try not to let CSS Dictate your HTML

First off, a cavate, unfortunately this can't always be avoided. Technologies like Grid and Flex have reduced the need for extra HTML scaffolding dramatically, but its not always avoidable.

This doesn't mean you should let CSS dictate the HTML you write. Treat HTML as a first class citizen, it is a language in its own right. Assistive technologies and search engine crawlers rely on it to understand your site. Two very important parts of any website. Treat it with respect and you will reap the rewards.

Be aware of your Media Queries

In my experience, media queries get more attention spent on the Developer ergonomic front, then in the User download front. The primary reason I say this is that media queries can be dynamically added to the page using the link media attribute.

This means that all of your CSS that you're using to make your site look nice on desktop and tablet, doesn't need to be downloaded by phone Users. So a clean media query strategy is a must for any project.

You also only need 1 media selector for each size you're targeting. Which hasn't been the common strategy I have come across.

The most common strategy I come across is media queries being added into the same file as the features styles. Leading to repeated media queries across multiple features. Essentially needlessly repeated CSS.

Think About the Future (But not too much)

Things change, and this needs to be part of the approach when implementing CSS. If a button design updates brand wide, it should update site wide in one easy place. And If a current feature has to fit into a new page it should be easily extended to achieve the new requirements.

All of this can be done by brute forced of course. But creating a clear way of working with CSS that stays predictable and maintainable is the primary success factor for any CSS system.

Scale in CSS is all about the future features not getting in the way of the past features, and a strategy that doesn't lead to a poor User download or a frustrating Developer experience.

In Closing

CSS is fun, complex, and has a lot to consider. These are the abstract ideas that I like to think about when writing CSS. Different CSS mythologies can help guide you in avoiding these issues. And some tools can just make them not a problem for the User. Just try to be aware because CSS won't yell at you, its that good friend that just helps you out without mentioning it. Even if its harming the friendship.

If you have any thoughts do reach out to me on twitter @LiamMyles92