DEV Community: Jon Major Condon

Build Reusable Testing Queries

Jon Major Condon — Tue, 11 Jun 2019 13:51:42 +0000

This post is inspired by a problem I had about two weeks ago; I wrote brittle tests that interacted with the Select component from React Material UI. After a bunch of time spent that day attempting many solutions, I landed on one that I am satisfied with... That solution is what I am sharing today!

TLDR; Keep a testbase maintainable and less brittle by sharing reusable DOM queries. The patterns for accessing "abstraction details" of a third-party component can change over time, but updates can be made in a single spot.

The Problem

I want to write tests that are maintainable and resemble the way my software is used. This means I need to simulate user interaction within components, including any third-party component. However...

Data attributes may not appear in a third-party component.
Data attributes may not appear on the intended element inside a third-party component.

I am a huge fan of data-testids, but I can't always rely upon them when working with a third-party component.

Quick Aside: The Material Select component uses react-select. This post will only use react-select in a contrived example...

After some debugging, I discovered an id on the input tag inside react-select.

<input
  aria-autocomplete="list"
  autocapitalize="none"
  autocomplete="off"
  autocorrect="off"
  id="react-select-2-input" {/* That's helpful! */}
  spellcheck="false"
  style="box-sizing: content-box; width: 2px; border: 0px; font-size: inherit; opacity: 1; outline: 0; padding: 0px;"
  tabindex="0"
  type="text"
  value=""
/>

After testing by querying for the id, I discovered that it increments based on the amount of rendered Select components on the page. I wouldn't trust this as a test id! This can potentially change at anytime causing cascading test failures. A good rule of thumb is to have a reserved id for testing. However, we don't have access to use data attributes or this id on input anymore... I would rather have an id on the root tag of the component anyways; then I can query anything scoped inside the component... Turns out, I can do this!

"Here is a hot take", if a component package does not allow data attributes, read the documentation and learn what can be passed as a substitute. There may be an id or something that can be rebranded as a test id. In my case, I can do exactly that. In my contrived example, I can create my own internal Select component that reintroduces react-select with a required dataTestId prop. Now I can use my internal component that has a trusted test id.

// Select.js
import ReactSelect from 'react-select'
import React from 'react'
import PropTypes from 'prop-types'

function Select({ dataTestId, ...props }) {
  return <ReactSelect {...props} id={dataTestId} />
}

Select.propTypes = {
  dataTestId: PropTypes.string.isRequired,
}

export default Select

The Solution

Let's carry on with some good old fashion “acceptance criteria.”

I see my selected value in the input field of the Select component
I see my selected value in the span directly below the Select component

Here is the working contrived example that meets the acceptance criteria, but we need tests to ensure we avoid regression in production!

import React from 'react'
import Select from './Select'

const options = [
  { value: 'chocolate', label: 'Chocolate' },
  { value: 'strawberry', label: 'Strawberry' },
  { value: 'vanilla', label: 'Vanilla' },
]

function App() {
  const [selectedOption, setSelectedOption] = React.useState({})

  return (
    <div>
      <Select
        dataTestId="select-ice-cream"
        value={selectedOption}
        onChange={valSelected => setSelectedOption(valSelected)}
        options={options}
      />
      <span data-testid="select-ice-cream-selected">You selected {selectedOption.value}</span>
    </div>
  )
}

export default App

If we were to inspect the third-party component, there's a lot of divs and stuff within it. A lot of "abstraction details" that we don't care about. It can be rather difficult testing an unmocked third-party component, but doing so gives me better confidence that the application works correctly. Alright, since we are not using data-testid, we cannot use the queryByTestId selector from React Testing Library. I am going to use the DOM querySelector instead...

it('renders without crashing', () => {
  const { container, debug } = render(<App />)
  const inputEl = container.querySelector('[id="select-ice-cream"] input')
  debug(inputEl)
})

I don't know of a React Testing Library query available to us that queries for an attribute. That's why we're using the DOM querySelector. We can do better though, we can turn the above into a custom query! And even better, I will return an object with elements that are needed for fulfilling the acceptance criteria!

it('shows selected value in input field and right below select', () => {
  const { querySelectComponent } = render(<App />, {
    queries: {
      ...queries,
      querySelectComponent: (root, id) => {
        return {
          rootEl: root.querySelector(`[id=${id}]`),
          inputEl: root.querySelector(`[id=${id}] input`),
          spanEl: document.querySelector(
            `div[id=${id}] + span[data-testid='${id}-selected']`
          ),
        }
      },
    },
  })

  const { rootEl, inputEl, spanEl } = querySelectComponent('select-ice-cream')

  fireEvent.change(inputEl, { target: { value: 'strawberry' } }) // change input value to strawberry
  fireEvent.keyDown(inputEl, { key: 'Tab', code: 9 }) // select what the input value has as the selected value

  //Assertions!
  expect(spanEl).toHaveTextContent(/strawberry/)
  expect(getByText(rootEl, 'Strawberry')).toHaveTextContent('Strawberry')   
})

The test block now covers the acceptance criteria! And yes, we have a very specific selector containing abstraction details. div[id=${id}] + span[data-testid='${id}-selected']. That selector is to make sure that the span appears directly below Select as the Acceptance Criteria describes. The user should select a value and see the selected value in the input field of Select and within the span directly below Select.

The current test block has queries to abstract the details of component selectors. It is ideal having the queries reusable inside any test block. Anyone who needs to interact with the Select component, can use the same selector patterns within their tests. Every test can reuse the same pattern for accessing abstraction details of a third-party component, or possibly an internal component. But when react-select updates, I can update my queries from a single spot!

//testUtils.js
export const selectComponentQueries = (root, id) => {
  return {
    rootEl: root.querySelector(`[id=${id}]`),
    inputEl: root.querySelector(`[id=${id}] input`),
    spanEl: document.querySelector(
      `div[id=${id}] + span[data-testid='${id}-selected']`
    ),
  }
}

//App.test.js
it('shows selected value in input field and right below select', () => {
  const { container } = render(<App />)

  const { rootEl, inputEl, spanEl } = selectComponentQueries(
    container,
    'select-ice-cream'
  )

  fireEvent.change(inputEl, { target: { value: 'strawberry' } })
  fireEvent.keyDown(inputEl, { key: 'Tab', code: 9 })

  expect(spanEl).toHaveTextContent(/strawberry/)
  expect(getByText(rootEl, 'Strawberry')).toHaveTextContent('Strawberry')
})

Conclusion

Abstraction details of components can change. Keep a testbase maintainable and less brittle with shareable test utils for something like queries. That way, all tests use the same reusable code. Having queries in a single source will allow change to come much easier.

Hello! I'm Jon Major Condon. I am a Senior Software Farmer that tends to client codebases at Bendyworks. As a farmer of software, I focus on anything web, but my curiosity usually leads me down rabbit holes... "Jon Major just fell down another rabbit hole… Stay tuned for the next blog post! 👋"

Gaining Followers. I must not know what I am talking about.

Jon Major Condon — Mon, 27 May 2019 16:34:37 +0000

I want to gain followers, but how? It's interesting, I have been asked this question a few times already this year. Do you want to know the unique thing about being asked this question? Me telling you will probably have you close this blog, but I am going to tell you anyways... Ready? Twitter is my social account with the most followers. I have less than 700 followers on Twitter... Twitter and Instagram combined I have less than 900 followers! Bye 😉

Okay, I am sure 90-ish% closed this blog. The rest of you, let's continue. Those who stuck around are probably super curious to why I am writing this blog with a follower count so little. Well, two reasons: I have been asked on occasion "how to gain followers" and writing this is me leading by example. There's no silver bullet, so here are some thoughts I remind myself.

Discover your passion/niche and create!

Publish content to a niche. You may not think you have a niche, but you probably do. It may be hard to see at the moment, but go and find it! If you don't have a niche, start with finding a passion. Your niche and passion are subject to change and that's life. Let's say you enjoy the latest and greatest mobile framework, Flutter. Go and write about it, Vlog about it, Instagram about it, sing about it, and get really weird about it...

Storytelling

It's a Journey to where you're going in life. People like me want to hear more about the journey! So whatever your passion is, I want to hear from you. I want to know the mistakes, struggles, and processes your passion is leading you down. The destination cares little about that stuff and cares more about "look at me -- I did it." Get used to talking about the journey.

Get used to talking to a wall

A lot of publishing when you have no followers is basically talking to a wall. The cool thing about social media is, it's socially acceptable. Don’t go talking to a real wall; we have social media now. Your content can have zero meaningful interactions and you shouldn't feel lesser about yourself. Keep talking to the wall we call social media. Eventually, you'll get a crowd. SNAP CRACKLE POP... Could it be why Facebook named where your posts go “the wall...” 🤔😂

Interact with your community

If it feels too much like you’re talking to a wall, interact with others. We can’t all be just posting and not engaging with others! Enter into a thread and share your passion, opinions, and be sure to ask questions before you just waltz in and share your opinions and tell everyone on that thread they’re wrong. Get more context so you can be thoughtful with your responses. That way your responses are actually helpful.

Cross-publish to Cross-Promote

Be everywhere! Saturate the internet along with everyone else. You're probably talking about something that's already in the ether, and that's okay. Folks like me will still read it and will begin to look at you as an expert. After cross-publishing awhile you may want to scale back and cross-promote. Basically, draw attention to one source, like your personal site, instead of a dozen sites.

Quantity will lead to Quality

I believe quantity will lead to quality. I tell myself this all the time. And it's okay if you suck, I do too. We all suck at some point.

Have Empathy

Most importantly, have empathy. There are a lot of haters out there. Don't hate back. You can turn a hater into a lover by just loving on them.

Don't aim for a "Following" count

Just create content, and folks will come.

Whatever it is, share it!

Share it. Share it. Share it. I know you know something that I don't, and you probably don't know what that something is. You only know what you know, so publish it. Let others find it and find either value or no value in it. Maybe no one finds value in it today or tomorrow, but maybe a month from now! "HA. A month from now. As we know, technology does move fast...” Okay, maybe it becomes outdated, but there is someone working on outdated software somewhere. I am positive whatever you publish, someone will find value in it at some point in time.

Conclusion

I, of course, have no idea what I am talking about because I don't have many followers. Good luck!

BEM in React

Jon Major Condon — Mon, 27 May 2019 13:01:12 +0000

I default to SCSS without modules for styling React applications. Therefore willingly my styles cascade. You're probably thinking, Eek! That means potential specificity wars ahead. Although there technically could be, each component uses a naming convention for class names.

Traditional BEM naming convention for class names is block__element--modifier.

A block is the element in your React component that wraps all other elements. There is only one block per component.
An Element is within the Block.
A Modifier represents behavior on an Element or Block.

Pretty simple right? Here is a start to a component.

const Counter = () => {
  return <div className="Counter">Start of an amazing counter component</div>
}

Notice: The class name is the name of the component with the same casing.

Let's extend that example so we can see more of BEM in action.

const Counter = () => {
  return (
    <div className="Counter">
      <button className="Counter__inc">Click me!</button>
      <span className="Counter__count">0</span>
      <button className="Counter__dec">Click me!</button>
    </div>
  )
}

Notice: The class name for elements are prefixed with the Block class name followed by a double underscore.

Let's add a modifier to this component!

const Counter = () => {
  return (
    <div className="Counter">
-      <button className="Counter__inc">Click me!</button>
+      <button className="Counter__inc Counter__inc--disabled" disabled>
        up
      </button>
      <span className="Counter__count">0</span>
-      <button className="Counter__dec">Click me!</button>
+      <button className="Counter__dec Counter__dec--disabled" disabled>
        down
      </button>
    </div>
  )
}

Notice: The original class name for an element is cloned, along with a double dash, followed by a modifier.

The buttons are now disabled. If you noticed, the buttons are missing click events anyways. For this demonstration, we don't really care to have a working example; we just want to see BEM. Theoretically, this application is looking good 🙃 We should have more confidence that styles are scoped to <Counter /> when it mounts!

The Post was growing too large. To keep it small and concise, and hopefully still digestible, I started with introducing BEM. I hope to move on to how I use BEM with 7-1 sass architecture and some other principles to create modular and maintainable style sheets! ...BEM is only part of the equation.

My "lightbulb" Moment!

Jon Major Condon — Wed, 30 Jan 2019 02:01:57 +0000

No matter how you started coding, you have had formative moments when learning. Reflect on one of your “lightbulb” moments when things started to “click." ~ Tea Break Challenge, Day #29

Almost six years ago... The beginning of my career, during college, I was hired as a part-time Mobile Software Developer consultant. I was hired with little to no knowledge on how to do the job — but, I was so determined... I went the entire first year without really understanding how to read API documentation; however, I was able to build my first production mobile application for a client within this first year! Although the app was a success, I really was still unsure about myself and how I was able to build it. The company I was working for then hired a new developer who was also aspiring to be a software developer, and it was me assigned to teach him "how to build mobile applications." — Whelp, so I did! I taught him how to read API documentation, And you know what...? That's when it clicked! I won't forget that "lightbulb!" moment, because I looked at him like... **** I know what I am talking about after all!

Teach and you will learn.

What's a lightbulb moment of yours?

Hello! I'm Jon Major Condon. I spend my days as a Software Farmer, tending to client codebases at Bendyworks. As a farmer of software, I focus on Javascript, CSS, and mainly React. That's not all though; I love spending my time with my wife and kids and focusing on my growth as a developer and helping others grow too! This year I am working to grow my writing skills, so I hope to publish some of my "Tea Break Challenge" responses and other posts involving anything life and dev related. I hope you enjoy!

What's the Tea break Challenge? Every day there is a new challenge to help developers connect with their inner-self. The Tea Break Challenge is also done by a phenomenal dev podcast called DeveloperTea

Teabreak Challenge #22

Jon Major Condon — Wed, 23 Jan 2019 01:22:20 +0000

The ability to focus is paramount to developer success. Determine your biggest enemy of focus today, and be aware of it as you take on your work. ~ Tea Break Challenge #22

The Enemy

Although "focus is paramount to developer success", it can be a wrecking ball to your productivity. Just because you're focused, does not mean you're being productive! Today, my "biggest enemy of focus" was having too much focus. I had a problem to solve and I was spinning my wheels, but I was too focused; I was unwilling to take a break... If you're like me, you do this far too often. You need to learn when to take a break.

The Solution

Take more breaks so I am accustomed to not being at the keyboard all day.
After spinning my wheels, start a timer and continue work until it ends. (Then take a break.)
Ask for another set of eyes.
Maintain productivity by taking breaks and working on meta tasks to keep me distracted from the original problem I was attempting to solve. (i.g. Slack, email, bathroom break, lunch, snack, etc.)

Maybe, just maybe... I need more coffee. Then I should be able to brute force my way to the solution! 🤔

What was the enemy blocking you from being focused today? Also, please help me out by suggesting any possible solutions for fighting my enemy!

Hello! I'm Jon Major Condon. I spend my days as a Software Farmer, tending to client codebases through Bendyworks. As a farmer of software, I focus on Javascript, CSS, and mainly React. That's not all though; I love spending my time with my wife and kids and focusing on my growth as a developer and helping others grow too! This year I am working to grow my writing skills, so I hope to publish some of my "Tea Break Challenge" responses and other posts involving anything life and dev related. I hope you enjoy!