DEV Community 👩‍💻👨‍💻

Cover image for Finding a bug after writing a test, an example
Alex
Alex

Posted on • Originally published at buaiscia.github.io

Finding a bug after writing a test, an example

Photo by Alan Emery on Unsplash

In almost every Sprint, at work, I try to reserve some space for solving tech debt and doing some refactoring. A part of resolving this debt is making integration tests. And sometimes it happens that those tests find some unknown bug. That's what happened a few days ago. As usual, the names of the methods and variables are just an example.

The page I was writing the tests on is a simple one. Some text, three buttons, and nothing more. Yet, it has some hooks as well, defining the logic of those buttons (opening another URL, submitting the form, etc).

I started writing the tests in the usual way, using React Testing Library. Checking the rendering and the behavior of the page by clicking on the different buttons. When I was writing the test for one of the three buttons, however, it forced me to let me think: is this button always visible? Why?

{showButton && (
   <Button onClick={onApplyClick}>
      DO THING
   </Button>
 )}
Enter fullscreen mode Exit fullscreen mode

I checked the hooks and found out that it would render only when another property was true, or present. So why it was always there?

  showButton: !!secondaryProp,
Enter fullscreen mode Exit fullscreen mode

I followed the source of that property and I came across the point where its data was fetched from the (easy-peasy) store, and then it was set as an initial value of 0, instead of being undefined.

const initialState: IState = {
  ...
  secondaryProp: 0,
Enter fullscreen mode Exit fullscreen mode

The type of that property was just "number", instead of "number?". So it was always true.

export interface IState {
  secondaryProp: number
Enter fullscreen mode Exit fullscreen mode

To fix it, I changed the type and set the initial values as undefined.

Re-checking that property I saw that another value was dependent on it being present or not. So in another hook, I had to redefine the behavior in case the prop was falsy.

const newUrl = secondaryProp && `${FETCHED_URL}/prop=${secondaryProp}`

const onClick = () => {
    if (!newUrl) {
      return
    }

    window.open(newUrl)
  }
Enter fullscreen mode Exit fullscreen mode

So that's an interesting case of how making tests helps you reflect on what the behavior, and the logic of the methods and components, should be.

Thank you for reading! Let's connect on Twitter or Mastodon!

Top comments (0)

We are hiring! Do you want to be our Senior Platform Engineer? Are you capable of chipping in across sysadmin, ops, and site reliability work, while supporting the open source stack that runs DEV and other communities?

This role might just be for you!

Apply now