DEV Community: Borislav Grigorov

Introduction to Testing React Components with Vite, Vitest and React Testing Library

Borislav Grigorov — Thu, 11 Jan 2024 14:25:56 +0000

Originally published on my blog: https://bogr.dev/blog/react-testing-intro/

This article assumes a certain level of agreement between me and you that testing the code we write as developers, is important. And also, that the best way to ensure our code has no bugs, is to write tests and run them as often as possible during the development lifecycle. I'll leave the discussion about the pros and cons of writing tests (and the different approaches in that matter) for another article.

In this article I want to walk you through the setup and writing of your very first test in React. Also, to provide some basic theory around the testing terminology and best practices. Meaning that this article is targeting mostly beginner JS/React developers, but could be a good starting point for any developer at any level of experience.

I hate long intros, so why don't we just dive right in.

What you're going to learn

How to setup a React project with Vite, Vitest and React Testing Library
How to implement a very basic quotes app, which shows a quote from an array and the user is able to navigate go to the next/previous quotes using previous and next buttons.
What's the difference between Unit and Integration tests.
What are some of the most common react-testing-library APIs (render, screen, query functions)
What's the difference between get, query and find query functions
The three As testing framework
Some best practices for writing React tests
I'll leave some of the tests for you to figure out by yourself. Remember - it's crucial apply the knowledge if you want it to stick.

Resources

GitHub repository with the code of our project. Feel free to clone it and experiment with it.

Project setup

Vite

First things first, let's setup a react project using Vite.

But what's vite, you may ask?

From vite's website:

Vite (French word for "quick", pronounced /vit/, like "veet") is a build tool that aims to provide a faster and leaner development experience.

We'll use Vite's superpowers to run a simple dev server for our React app while developing. Also, we'll use it to bundle the application later when we're ready to deploy (won't be covered in this article).

Create a React project with Vite

Let's start with creating a folder for the app. I'm naming my app rtl-vite.

mkdir rtl-vite && cd rtl-vite

Let's now create the React app with Vite. Run this in your terminal:

npm create vite@latest .

You're going to be asked what project scaffold do you want for your new Vite app.

For the sake of simplicity, I've picked the React with JavaScript template, but feel free to select the React with TypeScript one if you want to.

Installing dependencies

In order to test React apps, we need to bring in couple more libraries to our project.

Vitest and React Testing Library

Vitest is a next generation testing framework powered by Vite.

npm install -D vitest

The React Testing Library is a very light-weight solution for testing React components. It provides light utility functions on top of react-dom and react-dom/test-utils, in a way that encourages better testing practices.

The RTL is the primary tool we're going to use and interact with in this tutorial.

All the other tools are in a way "the infrastructure" around the testing itself.

So let's install that as well:

npm install -D @testing-library/react

Note: The -D flag installs the deps as dev dependencies.

Setting up the test globals and jsdom env

In order to save us some import statements in our test files and tell vitest that we want to use jsdom, update the exported config in your vite.config.js to the following:

src/vite.config.js

export default defineConfig({
  plugins: [react()],
  test: {
    // <--- Add this object
    globals: true,
    environment: "jsdom",
  },
});

Setting up a test script

We have the needed libraries, but how do we run the tests?

Let's add a test command to our package.json's scripts section:

package.json

"scripts": {
  ...
  "test": "vitest"
},

That's it.

We're now ready to roll.

The app

We need something to test, so let's create a very simple app.

Here's what we're going to build now:

A minimalist quotes application featuring a streamlined interface with two primary controls: a 'Previous' button and a 'Next' button. The application's central feature is a designated display area where quotes are presented. Upon the user's interaction with the 'Next' button, the application will display a new quote. When the 'Previous' button is clicked, the application will revert to showing the immediately preceding quote.

Let's go.

The `App` component

So, here's our App component.

src/App.jsx

import { useState } from "react";
import Quote from "./components/Quote";
import Previous from "./components/Previous";
import Next from "./components/Next";

import "./App.css";

export default function App({ quotes }) {
  const [currentIndex, setCurrentIndex] = useState(0);

  const navigate = (direction) => () => {
    let nextIndex = direction === "prev" ? currentIndex - 1 : currentIndex + 1;

    if (nextIndex >= quotes.length) {
      nextIndex = 0;
    }

    if (nextIndex < 0) {
      nextIndex = quotes.length - 1;
    }

    setCurrentIndex(nextIndex);
  };

  return (
    <div className="App">
      <div className="App__quoteContainer">
        <Quote quote={quotes[currentIndex]} />
      </div>

      <div className="App__navigation">
        <Previous onClick={navigate("prev")} />
        <Next onClick={navigate("next")} />
      </div>
    </div>
  );
}

To keep things simple, our quotes data is going to be an array with a few items.

The App component expects a list of quotes to be passed through its props.

Notice also that it keeps a reference to an internal state value called currentIndex, which is initially 0.

The navigate function is the meat of our app's functionality. That function gets called when the user navigates back and forth between the quotes.

In there we determine the next index, ensuring it's within the bounds of the quotes array.

The UI consists of the core component (<Quote />), followed by the two controls, wrapped in a div that lays them out on the x axis.

The quotes list

Ideally, our app would interact with some sort of an API to get a list of quotes.

But for the purposes of our exercise, we're going to keep things as simple as possible and define a simple array with a bunch of quotes.

src/quotes.js

export const quotes = [
  `“What greater gift than the love of a cat.” — Charles Dickens`,
  `“One of the ways in which cats show happiness is by sleeping.” —Cleveland Amory`,
  `“A cat will be your friend, but never your slave.” —Theophile Gautier`,
  `“No home is complete without the pitter-patter of kitty feet.” —Unknown`,
  `“As every cat owner knows, nobody owns a cat.” —Ellen Perry Berkeley`,
];

We're then passing the data to the App component like this:

src/main.jsx

...
  <React.StrictMode>
    <App quotes={quotes} />
  </React.StrictMode>
...

The `Quote` component

The Quote component is a pure functional component, which gets a quote and displays it. That's all.

src/components/Quote.jsx

import "./Quote.css";

export default function Quote({ quote }) {
  return <blockquote className="Quote">{quote}</blockquote>;
}

The navigation controls

For the navigation controls, we also have two functional components.

src/components/Previous.jsx

export default function Previous({ onClick }) {
  return (
    <button type="button" onClick={onClick}>
      Previous
    </button>
  );
}

src/components/Next.jsx

export default function Next({ onClick }) {
  return (
    <button type="button" onClick={onClick}>
      Next
    </button>
  );
}

Testing

Since we already have a simple, yet functional app, let's see what we can do to ensure any further development of features in the app goes smoothly and doesn't break any of the existing functionalities.

To do this, we're going to unit test the Quote, Previous and Next components, and also integration test the App component.

But before that, some theory.

Unit tests

In programming, a unit test is a piece of code that is written to test a single application module of a software system.

By module, we usually mean a tiny piece of functionality - a unit - that the program composes with other such pieces in order to do some task.

Just like lego blocks, where each block is a unit/module.

In the React world, you can think a React component as such a module. Thus, a unit test in React world is designed to test the behavior of a single React component.

Such components in our application are the Quote, Previous and Next. They are a single-purpose, pure functional components.

We're going to unit test them in a second, but before that, let's quickly remind ourselves what's integration testing.

Integration tests

Integration tests, are designed to verify that the interactions between two or more single-purpose modules in a software system run smoothly, without any bugs.

In other words, we test whether a group of units work together (interact) as expected.

In our application we have the App component which composes the rest of the components and that's a perfect candidate for an integration test.

Let's start with the simpler ones - the unit tests.

Testing the `Quote` component

Our Quote component is quite dumb and not much could break there. So it'd be enough to make sure it just renders properly as our first step.

Create a Quote.test.jsx file under src/components/ and paste that in:

import { render } from "@testing-library/react";
import Quote from "./Quote";

describe("Quote", () => {
  it("should render properly", () => {
    render(<Quote quote="What a nice day." />);
  });
});

So what's actually going on here?

The `describe` and `it` functions

Vitest, our testing framework, exposes couple of useful functions which we use to build our tests.

The first one is describe. Think of it as a way to group couple of tests that are related in some way or another into a single describe block.

Since we're going to write couple of tests that are testing our Quote component, I'm going to group them in a single describe block.

You can have as many describe blocks as you wish. Also, you can nest them.

My advice would be to keep things simple. Usually, a single describe block is more than enough.

As you can see from the code above, we put our tests inside of it functions. There's also a test function, which is basically the same - they're interchangeable.

it functions is where you put the actual test code.

Are they global?

Recall that in the beginning we added this to our vite.config.js file:

test: {
  globals: true,
  environment: 'jsdom',
},

What that does is to expose the describe and it functions on the global object. That means that we can now use those (and couple of other functions) right away, without importing them.

`render` is the first step

Take a look at our test again.

it("should render properly", () => {
  render(<Quote quote="What a nice day." />);
});

All it does is to render our component.

But where does it render it?

Well, the cool thing is it does it behind the scenes and you don't see it. Think of it as an invisible browser.

The render function call is the first step of a react test. You pass it the component you want to test, it does it's magic behind the scenes to generate the DOM for that component and after that you can interact with the rendered DOM, as if it was rendered in a browser.

That's the magic of react-testing-library.

Does it pass?

A test in Vitest passes if it doesn't throw an error.

In our case, we never return from our test, so if everything works, it should pass successfully.

Let's run it:

npm run test

And yes, as expected, our first test is successful:

Testing the `Previous` and `Next` components

Now things get a bit more interesting.

Our navigation components take a single prop. A function (onClick), which we run on button click.

What a good test for those components would be?

A good one would be to test whether or not the function gets called when a button is clicked, right?

Let's do this.

src/components/Previous.test.jsx

import { expect, vi } from "vitest";
import { render, screen, fireEvent } from "@testing-library/react";
import Previous from "./Previous";

const onClick = vi.fn();

describe("Previous", () => {
  it('should call "onClick" when a button is clicked', () => {
    render(<Previous onClick={onClick} />);

    const button = screen.getByRole("button");

    fireEvent.click(button);

    expect(onClick).toBeCalledTimes(1);
  });
});

Lots of things are happening there. Let's go through each of them one step at a time.

Mocking the `onClick` function

Just to remind you, our Previous and Next components get a callback function called onClick through their props. The the button is clicked, the function is called.

For the purposes of our test, we don't actually care what happens when the button is clicked. We care whether or not the function gets called.

A common approach when you want to check if a function/object is being properly used by the system under test is to create a mock function/object and check that expected calls are made to the mock function/object.

In vitest, you can mock a function, by creating a void one using vi.fn().

const onClick = vi.fn();

Arrange the stage

The first line of our test should be already familiar:

render(<Previous onClick={onClick} />);

We render the component and pass our mock onClick function to it.

But let's examine what happens on the next line:

const button = screen.getByRole("button");

It's pretty self-explanatory what that line does. But what's the deal with that screen and what's getByRole?

The screen object is a very important one. You're going to use it in most of your tests. It's always used in conjunction with render and both of these objects come from the react-testing-library package.

Think of the screen object as the "invisible browser", through which you can interact with the rendered DOM inside of the test. That object exposes a bunch of useful methods, which makes selecting elements on the DOM a trivial task.

In our example, we call the getByRole("button") to find the button in the rendered DOM.

Here's a list of the most commonly used methods that the screen exposes:

// getBy*
getByRole
getByLabelText
getByTestId
...

// getAllBy*
getAllByRole
getAllByLabelText
getAllByTestId
...

// queryBy*
queryByRole
queryByLabelText
queryByTestId

// queryBy*
queryAllByRole
queryAllByLabelText
queryAllByTestId

// findBy*
findByRole
findByLabelText
findByTestId
...

// findAllBy*
findAllByRole
findAllByLabelText
findAllByTestId
...

What's the difference between `getBy`, `getAllBy`, `queryBy`, `queryAllBy`, `findBy` and `findAllBy` in react-testing-library

We can group all six of these so called query functions in three groups: get, query and find query functions.

We use all of them to find elements on the rendered DOM.

getBy/getAllBy

The getBy and getAllBy functions do a synchroneus query on the DOM and throw an error if no elements are found, thus failing the test right away. As the name implies, the getBy is used to get a single element and the getAllBy is used for selecting multiple elements that match the given query.

queryBy/queryAllBy

The queryBy and queryAllBy do exactly the same, but they don't throw an error if no elements are found. That's useful when you need to do some conditional logic inside of your tests, based on the presence of an element, and not fail the test immediately.

findBy/findAllBy

We use the findBy and findAllBy when dealing with some sort of asynchrony in the component we're testing.

For example, when the component does a fetch request to some API and waits for the result to come in order to render a DOM element.

In that scenario, we can use find functions to "tell" react-testing-library that the DOM element we're looking for is going to be rendered after some delay (caused by the fetch in this case). So, the react-testing-library is going to wait for a certain amount of time for the element to appear and will throw after that time expires and no element is found.

Keep in mind that you need to await find operations, which makes the whole test async.

Example:

it("some async test", async () => { // <--- Notice the async
  render(<SomeComponent />)

  const el = await findByRole("button"); // <--- Notice the await

  ...
})

`Act`

OK, that's the theory around react-testing-library's query functions.

Back to our test.

After we have properly set the "stage" (rendered the component and got a reference to the button), we can proceed to doing the actual click.

For that we're going to need another function from the react-testing-library - fireEvent.

Again, as the name implies, that's how you trigger an event on a given DOM element.

fireEvent.click(button);

Simple, right?

`Assert`ing that the button works as `expect`ed

Now to the meat of our test - making sure that what we've done in the first 4 lines actually worked.

That's where the expect function comes in handy.

The expect function works like this:

You pass it an object and it gives you back a wrapper around that object, exposing a bunch of useful functions, such as toBe or toEqual and so on.

In our test, we pass it the onClick mock function and assert that it's being called once (toBeCalledTimes(1)).

expect(onClick).toBeCalledTimes(1);

That completes our test.

Now, try to write the test for the Next component by yourself. I won't give you the code here, but it should be identical to the one we wrote for the Previous component.

The best way to learn thins is to get your hands dirty, so go ahead and try.

The three `A`s of testing

When writing tests, a good framework to follow is the three As framework.

That stands for Arrange, Act, Assert.

Let's take a look at our test for the Previous component once again and notice the framework in action:

describe("Previous", () => {
  it('should call "onClick" when a button is clicked', () => {
    // Arrange (the stage)
    render(<Previous onClick={onClick} />);
    const button = screen.getByRole("button");

    // Act
    fireEvent.click(button);

    // Assert
    expect(onClick).toBeCalledTimes(1);
  });
});

Notice the comments. Those are the three main "blocks" in our test code.

The Arrange block is where you do the rendering and querying of elements. Basically, preparing the "stage" for action. Usually, you're going to see renders and screen operations in that block.

In the Act block goes all the code that does something on the stage. Usually, you're going to see some fireEvents here.

The Assert is where we validate our assumptions. We do expects here.

Some tests may have only Arrange and Assert, some may have only Assert, and others may have all three of them.

This is a universally applicable framework. You can think of your tests in three As regardless of the technology you're writing your tests on.

Now, let's write an integration test.

Integration testing the `App` component

It's time to make sure that the components that we compose inside of the App component interact as expected.

Here's our App.test.jsx file. Try to understand what's going on by yourself. In the next few sections we're going to break down each of the three integration tests.

src/App.test.jsx

import { render, fireEvent, screen } from "@testing-library/react";
import { quotes } from "./quotes";
import App from "./App";

describe("App", () => {
  it("shows first quote on app load", () => {
    render(<App quotes={quotes} />);
    const firstQuote = quotes[0];
    const quote = screen.getByTestId("quote");

    expect(quote.textContent).toBe(firstQuote);
  });

  it("shows next quote on `Next` button click", () => {
    render(<App quotes={quotes} />);
    const secondQuote = quotes[1];
    const quote = screen.getByTestId("quote");
    const nextButton = screen.getByTestId("next-button");

    fireEvent.click(nextButton);

    expect(quote.textContent).toBe(secondQuote);
  });

  it("shows previous quote on `Previous` button click", () => {
    render(<App quotes={quotes} />);
    const firstQuote = quotes[0];
    const quote = screen.getByTestId("quote");
    const nextButton = screen.getByTestId("next-button");
    const prevButton = screen.getByTestId("prev-button");

    fireEvent.click(nextButton);
    fireEvent.click(prevButton);

    expect(quote.textContent).toBe(firstQuote);
  });
});

Verify the `App` renders the first quote

The first test is going to verify that the App component properly initializes the Quote component with the first quote from the quotes array.

it("shows first quote on app load", () => {
  render(<App quotes={quotes} />);
  const firstQuote = quotes[0];
  const quote = screen.getByTestId("quote");

  expect(quote.textContent).toBe(firstQuote);
});

As you can see, we don't have an Act step here and that's totally fine. We just need to verify the text content of the quote element is the proper one.

Did you notice the getByTestId call?

What is a `testId`?

A testId is an easy way to get a handle of a given element in the DOM.

Think of it as an id, which you attach to the DOM element.

To make things simple for me, I have just attached data-testid="quote" test id to the Quote element, just like this:

src/components/Quote.jsx

...
    <blockquote className="Quote" data-testid="quote">
      {quote}
    </blockquote>
...
}

I also added test ids to the Previous and Next button components so that it's easier to query them in my tests:

src/components/Previous.jsx

export default function Previous({ onClick }) {
  return (
    <button type="button" onClick={onClick} data-testid="prev-button">
      Previous
    </button>
  );
}

src/components/Next.jsx

export default function Next({ onClick }) {
  return (
    <button type="button" onClick={onClick} data-testid="next-button">
      Next
    </button>
  );
}

Verify the quote changes to the next one on `Next` click

it("shows next quote on `Next` button click", () => {
  render(<App quotes={quotes} />);
  const secondQuote = quotes[1];
  const quote = screen.getByTestId("quote");
  const nextButton = screen.getByTestId("next-button");

  fireEvent.click(nextButton);

  expect(quote.textContent).toBe(secondQuote);
});

What do we have here?

In our Arrange block, we get a reference to the secondQuote, which we're going to use in our assert block.

Then, we query the quote and the nextButton elements, again by using getByTestId functions.

In the Act and Assert blocks we trigger a click event on the nextButton and then verify that the contents of the quote is the same as the secondQuote.

Easy peasy, lemon squeezy.

Verify the quote changes to the previous one on `Previous` click

it("shows previous quote on `Previous` button click", () => {
  render(<App quotes={quotes} />);
  const firstQuote = quotes[0];
  const quote = screen.getByTestId("quote");
  const nextButton = screen.getByTestId("next-button");
  const prevButton = screen.getByTestId("prev-button");

  fireEvent.click(nextButton);
  fireEvent.click(prevButton);

  expect(quote.textContent).toBe(firstQuote);
});

This time, in our Act stage, we do a next and then previous click and verify that the quote is back to the original one.

Pretty straight forward.

Interactions are crucial

Notice that in our integrations tests we test interactions between 2 or more components.

That's what makes a test an integration one.

Now it's your turn

I have intentionally left the tests for our array bounds logic. I'll leave that to you to figure out.

The general idea is as follows:

1. Test that when the app shows the first quote and the user clicks the "Previous" button, the next quote that's being shown is the last one in the data array.
2. Test that when the app shows the last quote and the user clicks the "Next" button, the next quote that's being shown is the first one in the data array.

Got it? Now write the tests. :)

Conclusion

I hope you had fun reading this article. It came out much longer than expected, but I think I've managed to show you the 80% of what testing a React application looks like.

Of course, we never touched asynchrony, testing hooks and what not, but that was not the idea of this article.

I'll do my best to write such guide on the topics I couldn't cover here, so you can subscribe using the form bellow to get notified when I do.

If you had any questions or comments, feel free to reach out. I'd be happy to discuss.

Take care.

My programming principles

Borislav Grigorov — Fri, 09 Apr 2021 15:42:52 +0000

A principle is a "fundamental truth or proposition, that serves as the foundation for a system of belief or behavior".

Simply put, it's the "why" behind our thoughts and actions.

If you want to understand why principles are important, how to expand horizontally and what does it mean for a design to emerge continue reading.

Why should I care?

Maybe you don't realize it, but you already operate on a set of internalized principles. It's one of these things that we let run in the background, without being conscious about it.

It's a good thing because we don't have to map every single thought or action to a principle in our head. It happens automatically. We don't have to think about it.

But on the other side, it's bad, because the mapping can go way off and map to some wrong conclusions about reality.

Here's an example.

We go to work or start a business, because we have to survive, but also because we know that a productive life is the most efficient way to survive. So, our principle is: do productive things to survive.

Now, if we had the wrong principle internalized and we weren't mindful about it, we would simply robber a bank and think it's OK. We have internalized a principle, based on which in order to survive we don't have to do anything productive. We're human beings and we deserve to be alive and have an "easy" life, so the "rich" guys at the bank must pay their social duty and we're allowed to go and take what belongs to us. Because we deserve it.

Now, it's clear that the wrong principle in the second example leads to bad life decisions. What's fascinating is that there are people that do think this way. People who internalized the wrong principle. And they don't even realize this.

Having the wrong principles without realizing it is way worse than having them and doing something about it.

That's why we should make it a routine to revise our framework. Not only in our professional field but in life, love, finance, etc. Our principles are the kernel of our operating system. They are the basis of the way we live, work and thrive. And if we're not mindful of the fundamentals, things can go really bad.

It's mental work that has to be done beforehand, a volitional effort which we must not skip!

The current article is in a way such a reflection, narrowed down to the principles in my craft.

What is a programming principle

It's a guiding set of truths for the way we structure our programs, devise solutions to problems, and approach common software tasks in the process of building a usable product.

DRY (Don't Repeat Yourself) is such a principle you might have heard of.

A (programming) principle should be general enough to serve as a useful heuristic in many seemingly unrelated scenarios. But it must not be too abstract, as it would be hard to apply to any concrete.

Let's get started with my set of principles in no particular order.

Simplicity is not a visual trait

I see many developers fall into the trap of the so-called "simplicity". What's propagated as simple these days is not simple at all, but merely a way to make it seem simple. It's an important observation.

I know, because I've been there, too.

Squeezing functions to no more than 3 lines of code. Refactoring if statements to a single line or, God forbid, polymorphism.

I get the hype.

But the way this hype is packaged and labeled as "simplicity" is merely wrong. It's false.

Look, by making a function three lines of code, it doesn't get simpler. It just gets faster to read. But not simpler.

It's like the tip of an iceberg. You see just 1% of the thing and the rest is drawn deep below the waters. And for what reason? To hide the fact that the iceberg is big?

Throughout the years I've seen so many icebergs, it's insane. And diving deep just to find out that it's so big, is a waste of energy.

You might think, well, ok, then what do you suggest, to write behemoth functions and turn my code into spaghetti?

Of course not.

I want you to be less concerned by the visual simplicity and more about the technical one.

If a thing is a thing(), don't make it a t(h(i(n(g)))). Don't make small t, h, i, n, g functions but leave the thing() as is. Even if it's 4+ lines of code (scary!). Some thing()s must stay thing()s.

Comments* on the way to prevent wrong abstractions

Another trap for inexperienced developers. The common wisdom that comments are bad.

I see where this comes from and I partially agree.

But not using comments can be as harmful as overusing them.

Let me explain.

When I was still a more junior developer, I was extracting functions out of nothing. Just to make my code more "expressive".

Extracting functions generally leads to the need to create new files and (probably) folders. It's like extracting the contents of your fridge into different fridges. One for eggs. One for ham. Another for the cheese and another one for the salads. You get the idea.

At first, you might think that now your food is neatly organized, but if you try it for a week, you'll quickly realize that what you did was a big mistake.

Now not only your fridges occupy more space at your home (whole fridge for 10 eggs, buddy!) but you have to keep a mental map of what belongs where.

The same was happening to me constantly. I was always overthinking how a piece of 2 lines of code should be organized by file/folder. Later when I had to use it, I had to reconstruct a mental map out of those pieces to make them fit together. Doing this exercise hundreds of times each day is a mind-draining experience.

Like trying to make dinner and having to open 20 fridges, one at a time, to see what's in there and come up with a recipe.

Good luck.

But why am I telling you this?

Because what I do nowadays is exactly the opposite. I never introduce new files/folders in my projects just to make things more "expressive". Part of what helps me stay disciplined in this regard is comments.

My use of comments is a way to prevent unintended, unneeded or simply wrong abstractions emerge.

Instead of extracting each line to make it more readable, I simply leave it as is, or if needed, write a one-line comment above it and call it a day.

This way everything stays in the same function/file (fridge). And everything has its own block (shelf, if you keep up with the fridge analogy). I just put labels in there and the thing gets much more readable with the added benefit that it stays compact at the same time.

At this point, a lot of people are screaming behind the screens. The most triggered ones even closed the tab. That's good.

I hear "and what about the fact that comments get outdated or even misleading, yadda, yadda"...

What if you put your eggs on the shelf with the ham? And even stick a tiny label on the eggs box saying "HAM". Are the eggs now ham? If you still get the eggs out of the fridge thinking that it's a ham, the problem most probably is not the shelf nor the label, but the subject that got the object out of the fridge. :)

I mean, the argument with the misleading comments sounds naive to me. We're not kids. You can stick a label to a car toy saying "SPACESHIP" and the kid would genuinely accept that it's exactly what it says. But a grownup would just fix the label and carry on (playing with the car toy :))).

Let's be honest here. Introducing new fridges is far more expensive than a misleading comment, which can just be deleted/fixed.

Design emerges

Let's do a quick thought experiment.

Imagine a completely blank world. Blank as a blank page. There's nothing, just ground.

Imagine you are a being that has no conceptual knowledge. No words, no terms, no experience, no previous perceptual data. You are a blank being in a blank world.

Now, could such a being come up with the term coffee shop?

Of course not.

To have the term coffee shop, you have to build on top of two other terms - coffee and shop. You have to construct their meanings. But to have the concept of coffee, you have to introduce the term plant and the term seed. To have the term shop, you have to introduce countless other concepts, such as building, cashier, money, trade, etc, etc.

It's obvious that having 0 reality, you're unable to construct higher concepts.

Yet, we still build software following exactly that same conviction.

We still build concepts, having close to zero understanding of the underlying reality.

In practice, this means that you cannot simply introduce a concept (think function/class/module) without having any evidence of what does the "internals" of the concept mean to the world (technical and business-wise), what it's based on and if it's a single event or a recurring pattern.

Going deeper into the details, having a loop that iterates a set of users, sends them emails, and assigns them a support team member, must not be immediately extracted to an onboardUsers() function. You must let "reality" (your program/business logic context) evolve to the point where it's obvious that sending emails and assigning the users a support guy is part of the onboarding process.

In that sense, the design of your code must emerge, it must not be forced by your subjective whims. Literally, a product development guy must write this spec down:

"The onboarding process consists of sending an email and assigning a support buddy".

This is reality, and having the concept of onboarding there, you're safe to step on it and introduce it to your software context.

Otherwise, let the loop be a loop and do its thing. Don't conceptualize it further. If it does many things, put a comment or two in there, but, please, don't introduce an "abstraction", a factory factory, a strategy, or whatever, where a comment would suffice. Concepts are easy to come up with but very hard to get disentangled.

Reuse consciously

The most fundamental thing you're going to learn in an Economics 101 class is the theory of division of labor.

This "invention" is one of the few tipping points in human history. It's the right way to leverage other's people potential. The same fundamental principle works in every possible field of human life.

In software, too.

We can take advantage of using other people's solutions to common problems in the form of frameworks and libraries. It's great to be able to step on a giant's shoulders and we must do it so that we're able to build meaningful products in time without going crazy.

But I want to stress something that I see a lot of people do wrong here. And that's going to the extreme.

Having easy access to working software pieces and gluing them together is tempting, especially when we're in a rush or just don't want to engage in the process of coming up with solutions ourselves. And here is the problem. We're so used to reusing other people's code, that this now serves as an excuse not to think. Which is dangerous.

See, solving problems involves thinking. It is inevitable. Yes, we can come up with something just by mindlessly gluing pieces together, but if we want to be good at it and if we want to design quality, resilient solutions, we must engage in a thinking process. We must get our hands dirty from time to time. Outsourcing critical thinking decisions to a framework or a library has its consequences, and we must be aware of what they are.

Reusing extraneous code is a choice. And as with every choice in our lives, it depends on the context.

My principle here is: Don't approach frameworks and libraries as defaults. Always consider reality, your context.

The last one is a bit more abstract. I've left it last intentionally. If you were to take a single principle out of this article, let it be this one.

Expand horizontally

The way I would solve a given problem will most probably be different from the way you would do it. That's why programming is mostly a creative activity. Beyond the most simplistic problems, there are countless possibilities.

But how does one come to a solution? I have a theory.

As with any other creative process out there, the result of coming up with a programming solution is a reflection of the creator's values, perceptions, fears, cravings, knowledge, etc. Our creative output is a mirror of ourselves.

Hence, the following is a leading principle for creatives:

Being creators/problem-solvers we have the responsibility to expand ourselves not only vertically, but horizontally, so that our creative output gets more expressive and sophisticated in the process.

Let's deconstruct the terms vertical and horizontal expansion.

A Go developer "expands" vertically his knowledge by digging deeper into the Go ecosystem, learning advanced Go techniques, building a portfolio of projects in that field. It's what's mostly known as specialization.

The same developer "expands" horizontally his knowledge by learning about economics, physics, reading fiction, studying philosophy, design, playing guitar, learning to brew beer, etc. Going a bit more narrow, learning Docker, Rust, and building iOS apps can also be considered horizontal expansion.

Every activity that adds another dimension to the knowledge base of a person can be considered widening horizontally. In other words, to get better at our craft, we must get better at any craft.

People that are good at this are commonly labeled generalists.

Why is that so important for creatives?

Because, unlike solutions, problems are not so unique. You'll be surprised to see that most of our software problems are already solved in some other seemingly unrelated field. Like architecture, for example. Or economics. Or physics, design, philosophy. And by expanding horizontally your knowledge and awareness of those problem/solution sets, you get smarter. You get more creative. You have more data points to play around with, to connect. It's just easier to see patterns, to spot weaknesses, to design working abstractions.

It's not a novel idea. But it's powerful enough to serve as a guiding fundamental principle in my life. Consider expanding horizontally and becoming better at other crafts!

As this article became fart too long for my taste, I'd rather end it here.

I certainly have a few more principles to share about programming (and to some degree about life in general), but I'm gonna leave it for another article.

Thanks for reading. 🙏

Massaging types in typescript (part 1)

Borislav Grigorov — Tue, 12 Jan 2021 07:25:43 +0000

TLDR;

In TypeScript, we can retrieve type information in many different ways. In type context we can use:

typeof - refer to the type of a value or a property: typeof "some string" is string; typeof 1 is number etc.
keyof - given an object, reduces it to an union of it's keys: type keys = keyof { name: "Bobi", age: 29 } resolves to the following type: type keys = "name" | "age"
indexed access - given type Person = { name: "Bobi" } and type PersonName = Person["name"], the PersonName resolves to string

TypeScript is great when it comes to types reusability. Once defined, a type can be "massaged" in order to suit different business logic needs.

Here's one simple example.

type Person = { name: string, age: number };

const person: Person = { name: "Bobi", age: 29 };

const updateName = (p: Person, name: string) => {
    p.name = name;
}

updateName(person, "John"); // { name: "John", age: 29 }

The updateName function accepts a person (Person) and a name, which is in the form of a string.

It's all great, but imagine we get new requirements, which say a user can have an empty (null) name.

We do:

type Person = { name: string | null, age: number };

Now we have to also update the type of the name argument in updateName like this:

const updateName = (person: Person, name: string | null) => {
    person.name = name;
}

This move can be skipped if we were using indexed types access for the name property of the Person type. Let me show you.

const updateName = (person: Person, name: Person["name"]) => {
    person.name = name;
}

Having this type definition, typescript is smart enough to resolve the type for the name argument by itself, using the type of Person.name. Which, of course, is string | null after the update with our new imaginary requirements.

That's the power of indexed types access

The `typeof`

Another handy keyword in TypeScript is typeof.

const names = ["John", "Mary"];

const emojify = (name: string) => {
    return `${name} 🤘`;
}

const process = (items: typeof names, processor: typeof emojify) => {
    return items.map(processor);
}

console.log(process(names, emojify)) // ["John 🤘", "Mary 🤘"]

Pay attention to the process function. It's items argument is anything that has the same type as names, which happens to be string[]. And the processor argument is anything that has the same type as emojify, which in the example is (string) => string.

We use type x = typeof y when we want tell the compiler: "Hey, compiler, whatever the type of that variable (y) is, use it as a type for this (x) variable".

The `keyof`

The last tool we're going to cover in the first part is keyof.

It's quite self explanatory. Let me show you.

type Subscriber = { id: number, email: string, topic: number };

type SubscriberProp = keyof subscriber; // "number" | email" | "topic"

Our SubscriptionDetail gets resolved to the keys of the Subscriber type. So we get type SubscriberDetail = "email" | "topic".

It's handy when we need something in the following fashion:

const getProp = (subscriber: Subscriber, prop: SubscriberProp) => {
    return subscriber[prop]
}

Part two is in the oven and is coming soon.

Photo by Hans Vivek on Unsplash

Using TypeScript Intersections to extend component's props in React

Borislav Grigorov — Sat, 09 Jan 2021 16:40:38 +0000

Every app has buttons.

So, let's create a Button component, which uses the button html element under the hood.

export default function Button({ children }: { children: React.ReactNode }) {
  return <button className="btn">{children}</button>
}

Easy peasy.

But in terms of functionality, our button is very limited. For example, having this implementation, we cannot handle any events, cannot extend the className, nor pass any style, disabled, etc. props to it. It's basically a very dumb component.

There are several possible approaches we can take in order to make it a useful one.

Props "babysitting" or any type

One way to do it is by "babysitting" every possible button property there is by ourselves. Like this:

export default function Button({
  children,
  onClick,
  style,
  disabled,
  // ... etc.
}: {
  children: React.ReactNode
  onClick: (e: MouseEvent) => void }
  style: { [key: string]: any
  disabled: boolean
  // ... etc.
}) {
  return (
    <button
      className="btn"
      onClick={onClick}
      style={style}
    >
      {children}
    </button>
  );
}

We can list all of native button's properties in our Button' s props, or some of them, but that's very tedious and far from scalable.

Another option is to use the any type and tell TypeScript that our component doesn't care about what types are the props it receives. I'm not going into details here, because any defeats the purpose of using TypeScript in the first place. And on top of that, using it is a strong sign for being lazy and we're not lazy. :)

So, there's a smarter approach.

Using `...rest` with TypeScript's intersections.

export default function Button({
  children,
  ...rest
}: {
  children: React.ReactNode
} & React.ComponentPropsWithoutRef<'button'>) {
  return (
    <button
      className="btn"
      {...rest}
    >
      {children}
    </button>
  );
}

Using the JavaScript's ...rest operator, we collect every possible property the user of the component passes to it in an array, called rest.

After that we "spread" the array in the <button>, making our Button component act as a "proxy".

One thing that's important to notice is the intersection type { ... } & React.ComponentPropsWithoutRef<'button'>.

This is how we tell TypeScript that our Button component may receive any of the native button's properties through the ...rest.

Sweet. We are happy. TypeScript is happy. 🎉

But we're not constrained only to extending props using only native HTML elements. We can do it with custom ones, too.

Here's an example, where we create an IconButton, which composes our Button component, but adds the ability to display an icon, next to the button's content. Notice that in this case we should use typeof Component to indicate that we're using a custom one.

export default function IconButton({
  icon,
    children,
  ...rest
}: {
  icon: React.ReactNode
} & React.ComponentPropsWithoutRef<typeof Button>) {
  return (
    <Button
      {...rest}
    >
      <Icon name="add" />
      {children}
    </Button>
  );
}

Conclusion

Use React.ComponentPropsWithoutRef<type> with intersections to compose custom component types. Forget about any and props "babysitting". Be smart and reuse whenever possible, whatever possible.

Here's very simple demo: https://codesandbox.io/s/morning-cache-3vzb4?file=/src/App.tsx

Programmer's first principles

Borislav Grigorov — Mon, 29 Jun 2020 15:40:18 +0000

Original article

Our job as developers is to solve problems. It's the programmer's axiom.

Thus everything we do that contributes to the realization of this goal is good (productive). Everything that contradicts and interferes with it - is bad (unproductive). At the end of the day we must ship solutions.

A fair question that arises is: How do we do this?

By observing objective truths from the reality in regards of your specific case and then implementing as much of the productive things (for that specific case) in your process as possible.

And how do we know if something is productive or not? Based on reasoning. In order to reason about something, one should have a solid foundation on top of which to build up and take logical decisions.

Here are some of the solid foundations that I use as a guiding light in my practice as a developer (and some of those to some extend as a human being in my life).

Simplicity over complexity. Always.
Automation over manual work - if machine can do it, it must do it.
If writing code can be avoided, avoid it. Remember the programmer's axiom - solve problems. It's not "write code".
Single point of failure is always preferable.
Remove what's not needed. It rots.
Duplicating code IS OK. Duplicating knowledge in separate modules IS NOT.
If it can be reused, reuse it. (Note: keep in mind simplicity)
Name things properly.
Do not succumb to the falacy that "there's no right or wrong approach". NO! There is! There always is. This fallacy is just an excuse. You should be aware of this and not allow it to influence your decisions.
No one knows better than you. Do not accept authorities telling you what's right and what's wrong. Figure it out yourself. Do not make the mistake to hand over your responsibility to some vague, anonymized authority. Make sure that the decisions you make (in your code and in life in general) are closed for the opportunity to blame others. You are the responsible one and you should be proud of it. That's what makes you a rational being.

Share some of the truths that guide YOU in your day-to-day problem-solving career.

Strive to get things wrong as soon as possible

Borislav Grigorov — Sat, 07 Sep 2019 18:56:47 +0000

Quite often people get stuck on a particular development problem and just sit there, staring at the screen for hours, hoping for the right solution to pop and enlighten their day.

And…it never does.

It turns out that developing software is far more different than solving problems in school.

In school you have a correct answer. That’s how teachers grade students (which is flawed by nature). In programming (and in life in general), you always have many right answers. That’s the beauty of it (and that’s why the school doesn’t work in practice).

So, instead of just sitting there and thinking about the big problem in front of you, what you could easily do is start experimenting. And more importantly – start failing as soon as possible.

I know, it sounds counterintuitive, but think about it for a second. You know the saying that every time you fail to do “the thing,” you discover a new way how not to do “the thing”. Therefore, why are you afraid of breaking things? Why are you afraid of being wrong?

In fact, being wrong is the inevitable step of the process to becoming right.

So, once again, what are you waiting for? You just waste precious time.

Start building, start breaking, start being wrong and get comfortable failing. It’s the yin-yang of the creator. You must be wrong in order to become right. So, please get things wrong. You’re not in school anymore.

DEV Community: Borislav Grigorov

Introduction to Testing React Components with Vite, Vitest and React Testing Library

What you're going to learn

Resources

Project setup

Vite

Create a React project with Vite

Installing dependencies

Vitest and React Testing Library

Setting up the test globals and jsdom env

Setting up a test script

The app

The App component

The quotes list

The Quote component

The navigation controls

Testing

Unit tests

Integration tests

Testing the Quote component

The describe and it functions

Are they global?

render is the first step

Does it pass?

Testing the Previous and Next components

Mocking the onClick function

Arrange the stage

What's the difference between getBy, getAllBy, queryBy, queryAllBy, findBy and findAllBy in react-testing-library

Act

Asserting that the button works as expected

The three As of testing

Integration testing the App component

Verify the App renders the first quote

What is a testId?

Verify the quote changes to the next one on Next click

Verify the quote changes to the previous one on Previous click

Interactions are crucial

Now it's your turn

Conclusion

My programming principles

Why should I care?

What is a programming principle

Simplicity is not a visual trait

Comments* on the way to prevent wrong abstractions

Design emerges

Reuse consciously

Expand horizontally

Massaging types in typescript (part 1)

The typeof

The keyof

Using TypeScript Intersections to extend component's props in React

Every app has buttons.

Props "babysitting" or any type

Using ...rest with TypeScript's intersections.

Conclusion

Programmer's first principles

Strive to get things wrong as soon as possible

The `App` component

The `Quote` component

Testing the `Quote` component

The `describe` and `it` functions

`render` is the first step

Testing the `Previous` and `Next` components

Mocking the `onClick` function

What's the difference between `getBy`, `getAllBy`, `queryBy`, `queryAllBy`, `findBy` and `findAllBy` in react-testing-library

`Act`

`Assert`ing that the button works as `expect`ed

The three `A`s of testing

Integration testing the `App` component

Verify the `App` renders the first quote

What is a `testId`?

Verify the quote changes to the next one on `Next` click

Verify the quote changes to the previous one on `Previous` click

The `typeof`

The `keyof`

Using `...rest` with TypeScript's intersections.