Gerg.dev has a new design! I spent the better part of this weekend writing a WordPress theme (mostly) from the ground up. As a tester dabbling in front-end development, here are some things I reflected on during this mini project.
I’m a #1xEngineer
This weekend, the #1xEngineer hashtag was all over my feed, as a response to someone describing what he called a “10x Engineer”: rockstar ninja gurus of the development world that never need to read documentation and don’t sully themselves with human interaction. The 1x variety are those of us who live in the real world, make mistakes, google things, and value collaboration.
As I was thumbing through these tweets on my phone, I also found myself googling gems like “css text italic”. (Turns out there was an
<em> inside an
<h2>to style it in a snippet I copied, which is not what em is for.) Pretty clear where I stand on the 1x to 10x scale in this case. While I do count this as the 2nd theme I’ve written myself, I can not claim that I wrote the first one any time this decade. I’m better at spotting errors in designs than avoiding them.
Flip side: my appreciation for skilled front-end developers continues to increase every time I try to take a picture in my head and turn it into CSS. It takes a lot of specific fiddly know-how. You folks are wizards.
Regressions come quickly
Often regression test suites are framed as something that might take some up-front investment but save you heaps 6 months down the road when someone else commits a breaking change to something.
That can also happen in the span of 6 minutes.
That’s especially true when actively moving component definitions around and refactoring the DOM. TDD comes to mind as one solution, of course, though most of my problems were with visuals rather than the underlying PHP. TDD at every level!
Visual tests would have been great
Given that the bulk of my bugs during development were around how things looked (it was a design challenge, after all) visual tests would have been a very easy way to get good regression coverage. With WordPress running on localhost, I could easily have set up some test data that contained all the elements I needed: featured media and no featured media, blockquotes, code snippets, heading levels, comments with or without threading, hover and focus styles, archive pages, tag pages, header and footer, etc.
Although, like any lazy developer (this was a weekend project, remember) I spent more time wishing I had tests than writing them.
MTDD is a thing
For better or worse, because I didn’t actually have any sort of automated tests, my development process was this:
- Make a change
- Refresh browser
- Google something
Manual test driven development. Doing a great disservice to manual testers out there, I know. Maybe “Curse Driven Development” would be more appropriate. Of course we all know the weaknesses of this. I test something with every change and to sure nothing broke, but a watched page never regresses. It’s always the other component you break.
Speaking of which…
Know what you’re testing
Nothing like developing in an unfamiliar environment to remind you of the basics. How many times did I refresh, not see the change I expected, and then go back to the code to tweak something, only to realize that I hadn’t cleared the cache or was looking at the wrong page. More times than I’d like to admit.
Quality aspects can focus everything
Though my main goal was just to get something functional that could replace the existing theme, the reason I was doing it was to simplify.
In TestSphere terms, I had just one quality aspect in mind: Simplicity.
I wanted the layout to be simple, yes, but I also wanted the HTML, CSS, and PHP simple too. I wanted to be able to understand it. I didn’t want divs on divs on divs. If a component didn’t fit on one screen, it was too big. I didn’t want to have to rely on tricks like
</div><!-- .content --> to tell me which div I was closing.
This was great because it didn’t just serve as a heuristic for making layout decisions, but it also guided how I structured the code. I could still feel productive when I refactored code to make it simpler even though the user-facing side didn’t change. The end result was that the more I worked on it, the more the code itself started looking like a design pattern library.
Simplicity was also the banner under which I wanted to address everything I’ve been learning about accessibility. The two can go hand in hand. I’m very glad that I’m no longer using
h tags as shorthand for different font sizes the way my old theme did.
Third parties will get you every time
The trickiest bits always came down to the 3rd party widgets. Some had awkward markup that I couldn’t subject to my simplification scalpel. Styles couldn’t be applied to some components at all. Accessibility concerns had to be bandaged over with hacks instead of fixing the root problem. Bugs will remain bugs for the foreseeable future. And of course, good luck setting up a sensible way of testing locally. Most ended up getting turned off.
You’re as good as the tools you use
When I say I wrote this theme from the ground up, that really involves a lot of referencing official docs and examples and other themes. But because these things don’t come naturally, it’s useful to call out the extra tools I used in case they may be useful to others: ColorSpace for developing a colour palette, WebAIM Color Contrast checker and Accessibility Insights for some level of quality control, Stylebot to be able to experiment live with CSS where the WordPress’s built-in CSS editor failed, XAMPP to host a local dev environment, and CodePen as a concrete reference for lofty ideas.
There’s always 3 more things to do
I have a lengthy
todo.txt file still. This thing isn’t perfect. Long term goals stretch all the way to generalizing the code enough to make it available to others. Maybe I actually will put together a visual testing suite and put it up on github. Short term goals involve getting those two divs to wrap properly on mobile (they know which ones they are).
But, now that it’s live, it’s a legacy product and my attention will probably wander to the next shiny side project nearby. So it goes. Put bugs in the comments and I’ll add them to the backlog.