DEV Community: Łukasz Makuch

It's 2020. Why is testing front-end applications so hard?

Łukasz Makuch — Wed, 15 Apr 2020 17:56:46 +0000

In his book "Thinking, Fast and Slow", the Nobel Prize-winning psychologist Daniel Kahneman writes about the idea of substitution. It's a mechanism that enables us to quickly answer difficult questions by replacing them with similar, but easier questions. For example, when asked if it makes sense to invest in Apple stock, we may say whether we like Apple products, without even noticing that we didn't answer the original question. Recently it occurred to me that this phenomenon may be observed in testing front-end applications as well.

The front-end world is evolving rapidly. We can see people from various backgrounds getting into it. Some of them, including myself, used to be back-end developers. When facing a serious challenge, such as "How do I test this application?", having some experience in a similar field puts us at risk of unconsciously answering a different question, like "Which parts of this application do I know how to test?".

If we know how to test a method returning an integer, we may try to interact with a front-end application as if it were an object with a method returning an integer. For example, we may count the number of table row nodes in the DOM, without even checking that they are rendered one after another instead of on top of each other. Or if we are no strangers to string comparison, we may settle for checking if the value of a DOM Text node matches our expectations, without verifying that the font is readable.

Does that make the tests we write useless? Not necessarily. They may be testing something after all. When in doubt, I ask myself whether I'd still write similar assertions even if the code I think I'm testing didn't run in a browser. Looking from 30 000 feet, would the tests still look the same, even if the app was a command-line utility or a REST API? If yes, then I may be testing everything but the very front end of my front end. And if that question doesn't help, I use the font-weight benchmark for front-end tests.

What does the font-weight property tell us about automated testing in the front-end world?

Łukasz Makuch — Mon, 09 Mar 2020 07:29:35 +0000

I've been lucky enough to start my career as a software developer in the era when automated testing was already a thing. If not always the reality, then at least a thing people talked about. And that's why since my very first year as a professional developer, inspired by Kent Beck's and Uncle Bob's books, I've been trying to automate testing the systems I worked on, with varying degrees of success.

After a couple of years of working as a back-end developer, I often knew which testing strategies would pay off, and which ones would bite me. I didn't feel overwhelmed or lost on a daily basis anymore. Actually, I felt pretty proficient at my job. I knew how to leverage automated tests to fill me with confidence that the software I was building actually did what I expected it to do. But then I grew interested in front-end web development, with all its quirks and wonders. The period when I handed a ThinkPad back, got a Mac, and tasted the famous Starbucks coffee marked the beginning of me as a professional front-end developer.

But something wasn't right. I didn't feel as safe as I used to. Initially, I blamed it on various non-technical aspects of my new job, such as joining a new company or moving to a new country. Or maybe it was the coffee? However, soon I realized that the real issue was an industry-wide lack of a quality safety net. And by the industry, I mean the front-end industry. We are the people tasked with getting some data, presenting it to the user, responding to their input and possibly sending some data back to the back end. Yet, the most popular testing approaches closely resemble what we developed to test back-end systems, with just a hint of the front end.

To help me differentiate front-end testing tools from some sort of back-end testing tools or half-baked front-end testing tools, I developed a little benchmark, and I think you may find it helpful as well. Before I reveal it to you, I'd really like to highlight the fact that it relies on the assumption that the purpose of automated tests is to tell us when the behavior of the system changes and in the same time let us change the implementation, as long as the behavior stays intact, without any need of touching the tests.

Here comes the font-weight benchmark for front-end testing tooling.

Imagine that as part of your job you wrote the following CSS code:

font-weight: bold;

What would happen if you refactored it to use a number instead of a word?

font-weight: 700;

It's good if your tests still pass. It proves that they are not tightly coupled to the implementation details. In the end, both bold and 700 lead to the same behavior of your app.
But if your tests fail, then it means they are tightly coupled to the implementation and will, in fact, make any refactoring harder.

Finally, what would happen if you made a mistake when refactoring the code above and instead wrote this?

font-weight: 800;

It's good if your tests fail now. It means they are actually testing what the front-end development is all about, which is rendering the right pixels in the right order and at the right time.
But if they keep passing, then it is a sign that the front end of your front end may have 0% test coverage.

The new CSS Grid will change the way you think about layouts. Here's why.

Łukasz Makuch — Thu, 23 Jan 2020 18:53:29 +0000

The first CSS Grid Layout made it possible to divide the area of an element with horizontal and vertical lines. These lines dictated the size and position of its children.

But this is going to change.

To understand why, and most importantly, how, let's recap the way things worked in the first version of the grid.

For instance, this card could be one grid:

The HTML code looks simple. It's just one parent with two children:

<div class="card">
  <img class="avatar" src="https://picsum.photos/id/10/200/200"/>
  <h2 class="card__text">Lorem Ipsum</h2>
</div>

The CSS code makes the parent element a grid:

.card {
  display: grid;
  grid-template-columns: max-content 1fr;
  grid-gap: 10px;
  align-items: center;
}

The grid lines are as follows:

Another card could be another isolated grid:

And the header could be yet another grid, built in the same way:

Let's put the previously discussed components together, just like that:

The parent element is yet another grid, just to define the spacing among the cards and the header:

.grid {
  display: grid;
  grid-gap: 20px;
}

It doesn't look bad.

However, it's quite optimistic to assume that in real life all the cards will have identical content. So let's make it a bit more realistic:

That's the problem I wanted to show you. As we can see, the texts are not really aligned with each other:

Luckily for us, the new CSS Grid Layout provides an elegant solution to this ugly problem!

We can define a single grid line that will be used to divide all the cards and the header together, on a higher level, above the individual elements:

First, let's define one grid at the parent's level instead of defining multiple grids for each child:

.grid {
  display: grid;
  grid-template-columns: max-content 1fr;
}

Then it's enough that we use the new subgrid option. It means that both the .header and the .card elements don't define their own grid lines, but instead, they inherit them from their parent element:

.header {
  /* 1 / -1 to make it span across the whole container. */
  grid-column: 1 / -1;
  grid-template-columns: subgrid;
}

.card {
  grid-column: 1 / -1;
  grid-template-columns: subgrid;
}

And... that'd be it!

The complete code of this example may be found on CodePen.

Subgrids from CSS Grid Level 2 enabled us to define cross-component alignment rules that work well even for dynamic content.

Just to be fair, I got to say that designers have been talking about it for ages! Maybe they called it differently, like keylines in Material Design, but anyway, it's nothing new to them!

So is the new specification a spacing nirvana? Not yet. By looking at some ongoing discussions about possible extensions of the subgrid we can tell that there's still some room for improvement. But it's already a big step towards unifying the ways designers and developers think. Now when somebody says "We need to align these components to this line." we can actually code "this line".

React hooks... Oops! Part 1 - Introduction

Łukasz Makuch — Fri, 04 Oct 2019 06:02:16 +0000

Familiarity makes us feel safe and confident. Yet, what's just familiar isn't exactly equal.

I believe that's the very reason why it's both so tempting and dangerous to start relying on a new tool, regardless how familiar does it seem to be, without first understanding what makes it different from what we already know.

React hooks are one of these new, shiny tools. Not only they are hip, but also some of them look pretty familiar and easy to use, like the useState hook.

But there's a catch to it - they are more of low-level building blocks that enable us to construct our own abstractions than something designed to directly solve everyday problems.

They are intended to be a way for the community to build and share cohesive fragments of logic, not a drop-in replacement for effectful methods in classes.

Of course that doesn't mean that the built-in hooks cannot be useful on their own. If using a handful of them actually solves the problem, that's great! But if I learned anything important about hooks, it's that as soon as I get plenty of them in a single component, I should stop and think whether that's the way to go.

More often than not, multiple interconnected hooks are a sign that there's an abstraction waiting to be extracted. Sometimes it may be possible to use an off-the-shelf hook, and other times, we may need to extract one ourselves.

You known what they say about mistakes. We can learn from them. And I must admit that I learned plenty of lessons that way. In this series, I'm going to tell you about mistakes made when building custom hooks, so that you can avoid them.

Stay tuned for the next post!