Brad Frost recently shared a post called “My Struggle to Learn React”. Inspired by that, I thought I’d share something I’m bad at: Testing Code.

This has been on my “List of Shame” for a long time. For a plethora of reasons, fostering a practice of writing and maintaining good tests for code has escaped me. It’s not due to negligence; I see the value, I’ve tried, I read a lot of code, I even took an in-person course once. My struggle is with taking that knowledge and applying it to my codebase.

I’m bad at drawing the rest of the owl

How to draw an owl. 1. Draw some circles. 2. Draw the rest of the fucking owl.

You know that old meme, the one about drawing the owl. I’m bad at that.

Testing tutorials are super basic. assert( add(1,2) ).equalTo(3) is cool and easy, I’ve watched hours of YouTubes on this stuff, then the tutorial ends and they’re like “So now you know how to do unit testing! Good luck. Smash that Like button.” Then I look at my mostly basic-ass DOM manipulation code and I’m lost on how to test it.

And I know that unit testing logic and functional/integration testing DOM manipulation is different. But again, there’s a gulf in my mind between expect(page.title).toBe('hello world') and “Make sure this doesn’t fuck up when resizing Internet Explorer 10 between 720px and 800px.”

I think it comes down to the fact that full test suites haven’t been demanded of me in my 10+ years of client work, therefore I possess no skill in this domain. That’s a good Get Out of Jail Free card for interviews, but what concerns me is my inability to even spot code that I can easily test.

Another area I fail to draw the rest of the owl is around the not-so-new’ish practice of spinning expensive JavaScript operations off the Main UI thread and into a Web Worker thread. This makes total sense to me. I know that anytime you use async/await is a hint to spin out a worker. But then I look at my code and can’t really find any jumping points to make that optimization.

Maybe it’s me.
Maybe it’s my code.

And heck. If I had code of sufficient size that could spin off into a Worker thread to improve performance, I’d probably not write that in JavaScript. I’d probably be looking at Web Assembly to avoid parse and compile times on expensive operations. Right?

Essentially these are all the same problem. I can’t seem to find ways to decouple my code and logic into testable and/or lazy-executable units. Again, maybe it’s the code I write. Maybe I’m destined to toil on the Main UI thread. Code that updates ARIA attributes isn’t rocket science, but it should be tested so that it’s done right, but then could I write tests better than aXe? I don’t know the answer to this question.

I spend every day of my work life breaking up sites into modules and components, it escapes me why I struggle to do this at the code level. If anyone has any resources (NOT intro-level tutorials) or experience on how to unlock this part of my brain I’d love to hear them. I’d love to read blog posts on how you test your frontend code. What are you testing in your frontend components for? I’d also love to know if you picked testing up yourself or if testing was mandated by your job.