DEV Community: Daniel Irvine 🏳️‍🌈

Staying out of trouble

Daniel Irvine 🏳️‍🌈 — Mon, 07 Sep 2020 20:21:11 +0000

This is the final part of a series on React component mocks. We’ll wrap up with a recap and then look at some common difficulties that you’ll encounter.

All the code samples for this post are available at the following repo.

dirv / mocking-react-components

An example of how to mock React components

Mocks are a notoriously difficult testing facility. That’s why some educators don’t use and don’t teach them.

But mastering mocks will make give you an extra weapon to fight brittle, time-sinking tests.

So how can you ensure you stay safe with mocks? Simple: stick to the patterns!

Stick to the patterns

If you stick to the patterns I’ve shown you in this series, you shouldn’t have problems.

Start with the basic mock function which renders a div with a data-testid attached. We looked at this in part two.

jest.mock("../src/PostContent", () => ({
  PostContent: jest.fn(() => (
    <div data-testid="PostContent" />
  ))
}))

If you need to, you can render children too. That was described in part three.

   jest.mock("../src/PostContent", () => ({
     PostContent: jest.fn(({ children }) => (
       <div data-testid="PostContent">{children}</div>
     ))
   }))

If you really need to, you can use prop value to make unique data-testids. But this is often unnecessary complexity. That was in part four.

jest.mock("../src/PostContent", () => ({
  PostContent: jest.fn(({ children, id }) => <div data-testid={`PostContent-${id}`}>{children}</div>)
}))

I always dislike giving any kind of advice on what to avoid: every technique has its place. But if I was to name one thing to be careful about, I’d say it would be building fakes and in particular use of the Jest function mockImplementation.

Why? Well, a major reason for using spies and stubs is to help build independent test suites that don’t slow you down.

An important way to do that is to restrict your code to a small number of patterns. It’s a little bit like having a set of coding standards, but at a higher level.

When you start building fakes and elaborate mock implementations, you are moving away from that goal because now you have logic within your tests: you can’t glance at them and immediately know how they work. And any change to the production code requires you to re-understand the fake implementation code before inevitably changing that too.

Conversely, when you stick to the handful of mock patterns I’ve shown you, you will get faster and faster at writing tests that use them. That’s because you recognise the patterns and don’t need to re-evaluate them in your brain each time you see them.

What if none of the patterns works for your test suites?

If you’re stuck, the first question to ask yourself is: how testable is my production code?

Because it’s not mocks that are causing you test pain, but production code that isn’t structured for testability.

Improving the testability of your code

The number one problem I see with React codebases is very large components that express many different ideas. Often, new features are just piled on top of each other rather than taking time to sort out abstractions or find a logical organisational structure.

So a good place to start is to split your large components apart.

How large is large? File size is often a good metric to use: for me, anything more than 100 lines is suspect. And many of my components are fewer than 10 lines in size!

What if it’s not obvious how to split a component? Start with the single responsibility principle: each component should do one thing and one thing only.

Of course, the notion of one “thing” leaves you plenty of rope to hang yourself. Figuring out elegant “things” is most of the difficulty in software design.

If you’re interested in this topic then I’d suggest learning about coupling, cohesion and connascence, all of which apply to React components, even though you won’t often hear React educators talking about them.

Where to go from here

In this series I’ve shown you a very specific way to test React components. If you’re interested in more detailed theory and history about these techniques, then take a look at my book, Mastering React Test-Driven Development. It doesn’t use React Testing Library but instead explores testing from first principles. Doing that will give you a much deeper understanding of successful React testing.

Testing multiple instances of the same mocked component

Daniel Irvine 🏳️‍🌈 — Mon, 07 Sep 2020 20:21:04 +0000

This is part four of a series on testing React with component mocks. In part 2 we looked at the basic form of component mocks. In part 3, we added the ability to assert on component children. Now we’ll look at the most complex piece of the puzzle: handling multiple instances of the same mock.

All the code samples for this post are available at the following repo.

dirv / mocking-react-components

An example of how to mock React components

Let’s continue with a new component, TopFivePostsPage, which perhaps unsurprisingly shows the top five posts.



import { PostContent } from "./PostContent"

export const TopFivePostsPage = () => (
  <ol>
    <PostContent id="top1" />
    <PostContent id="top2" />
    <PostContent id="top3" />
    <PostContent id="top4" />
    <PostContent id="top5" />
  </ol>
);

To test that, we use queryAllByTestId in combination with the toHaveLength matcher.



describe("BlogPage", () => {
  it("renders five PostContent components", () => {
    render(<TopFivePostsPage />)
    expect(screen.queryAllByTestId("PostContent"))
      .toHaveLength(5)
  })
})

And for our second test, we can use five expect statements, each with the different prop values.



it("constructs a PostContent for each top 5 entry", () => {
  render(<TopFivePostsPage />)
  expect(PostContent).toHaveBeenCalledWith(
    { id: "top1" }, expect.anything())
  expect(PostContent).toHaveBeenCalledWith(
    { id: "top2" }, expect.anything())
  expect(PostContent).toHaveBeenCalledWith(
    { id: "top3" }, expect.anything())
  expect(PostContent).toHaveBeenCalledWith(
    { id: "top4" }, expect.anything())
  expect(PostContent).toHaveBeenCalledWith(
    { id: "top5" }, expect.anything())
})

But there’s something not quite right about this. We haven’t tested the order of rendering. The toHaveBeenCalledWith matcher doesn’t care about order.

We can use .mock.calls instead.



it("renders PostContent items in the right order", () => {
  render(<TopFivePostsPage />)
  const postContentIds = PostContent.mock.calls.map(
    args => args[0].id)

  expect(postContentIds).toEqual([
    "top1", "top2", "top3", "top4", "top5"
  ])
})

If you try running this after the first two tests for TopFivePostsPage, you’ll get a strange error that PostContent was actually called fifteen times! That’s because when we need to clear our mock between each test.

We do that by adding the clearMocks property to our Jest config. Here’s my package.json for comparison.



"jest": {
  "transform": {
    "^.+\\.jsx?$": "babel-jest"
  },
  "setupFilesAfterEnv": ["./jest.setup.js"],
  "clearMocks": true
}

Notice the last test we wrote actually makes the previous test redundant, so you can delete that one safely.

When that’s not enough: mock instance IDs

Very occasionally, you'll need more than this. For example, if you need to test children passed and you also have multiple instances. In that case, you can use one of the component’s props to give a unique test ID to your component instance.



jest.mock("../src/PostContent", () => ({
  PostContent: jest.fn(({ children, id }) => (
    <div data-testid={`PostContent-${id}`}>
      {children}
    </div>
  ))
}))

Personally, I really dislike this. It’s complex, and more complex than I’m comfortable with. But it exists, and sometimes it’s necessary to use it.

Remember that mocks are there to help you speed up your testing, and testing is there to help speed up your development. When mocks become overly complex, you have to spend more time reading them and maintaining them, so they slow you down. I’ll cover more on this in the next part.

Yet more lessons

So what have we learned now?

Use queryAllByTestId when testing multiple instances of a mocked component
Use .mock.calls to check ordering of calls, or for testing render props.
Use Jest’s clearMocks configuration setting to ensure your spies are cleared before each test.
If all else fails, you can use props within your rendered output to give unique data-testid values for each instance.
Keep your mocks as simple as possible!

That’s all there is to it. In the final part, we’ll look at why mocks can get you into trouble—and how to avoid it.

Verifying children passed to React mock components

Daniel Irvine 🏳️‍🌈 — Mon, 07 Sep 2020 20:20:49 +0000

This is the third part in a series on React testing. In the last part, we looked at the basic form of React component mocks.

Another thing you might want to do with mocks is test that it has the correct children passed. That’s what we’ll look at now.

All the code samples for this post are available at the following repo.

dirv / mocking-react-components

An example of how to mock React components

Imagine that we want to inset a mailing list sign up form inside of the PostContent. We can do that by passing children elements to it.

Here’s the newly improved BlogPage component:

export const BlogPage = ({ url }) => {

  const id = getPostIdFromUrl(url)

  const handleSignUp = () => {
    // ...
  }

  return (
    <PostContent id={id}>
      <input type="email" placeholder="Sign up to my mailing list!" />
      <button onClick={handleSignUp}>Sign up</button>
    </PostContent>
  )
}

Crucially, our BlogPage tests shouldn’t care what PostContent does with the children. They should just care that it was given the children.

We could test this by pulling out the children prop from the .mock.calls entry and then rendering it with render. In other words, treating it like a render prop.

But there’s a more straightforward way, which is to modify the mock component to render its children:

jest.mock("../src/PostContent", () => ({
  PostContent: jest.fn(({ children }) => (
    <div data-testid="PostContent">{children}</div>
  ))
}))

Now we can write a test that checks that a button was rendered as a child of PostContent:

it("renders the mailing list sign up button as a child of PostContent", () => {
  render(<BlogPage url="http://example.com/blog/my-web-page" />)

  const postContentElement = screen.getByTestId("PostContent")

  const button = screen.queryByRole(
    "button", { name: "Sign up" })

  expect(postContentElement).toContainElement(button)
})

The same technique can be repeated for the input field.

If you run this test, you’ll notice a problem. Our previous test that checks the passed props is now failing. Its expectation looked like this:

  expect(PostContent).toHaveBeenCalledWith(
    { id: postId },
    expect.anything())

It’s failing because all of a sudden we have a children prop, which is unexpected according to this test.

We fix that using expect.objectContaining.

Use `expect.objectContaining` to narrow down your tests

It’s often useful to have multiple unit tests for a single mock component call! I usually start with one test, with all props specified. But for any prop values of sufficient complexity, it can be useful to split that out into a test of its own with a good test description. The children prop is a special case of that: our test that checks we pass the right ID is independent of anything to do with the displaying inset content.

We can avoid testing content by using expect.objectContaining in our expectation:

  expect(PostContent).toHaveBeenCalledWith(
    expect.objectContaining({ id: postId }),
    expect.anything())

More lessons

So what have we learned now?

To test children passed to mocks, modify the mock component to be `jest.fn(({ children }) = {children})
Use toContainElement from the jest-dom matchers package to check that components are rendered as children of your mocked component.
Use expect.objectContaining to write unit tests that don’t break when your props change.
Use Jest’s clearMocks configuration setting to ensure your spies are cleared before each test.

In part 4, we’ll see how we go about testing multiple rendered instances of the same mock component.

The basic form for React component mocks

Daniel Irvine 🏳️‍🌈 — Mon, 07 Sep 2020 20:20:36 +0000

In the first part of this series I looked at why mocking is useful.

In this part I’ll cover the basic format of React mock components.

All the code samples for this post are available at the following repo.

dirv / mocking-react-components

An example of how to mock React components

Let’s look again at the components we’re working with: BlogPage and PostContent.

Here’s BlogPage:

const getPostIdFromUrl = url =>
  url.substr(url.lastIndexOf("/") + 1)

export const BlogPage = ({ url }) => {

  const id = getPostIdFromUrl(url)

  return (
    <PostContent id={id} />
  )
}

BlogPage doesn’t do much other than show a PostContent. But it does have a little piece of functionality that we’re interested in, which is parsing the url prop value to pull out the required post id.

PostContent is a little more complicated: it calls the browser’s in-built fetch function to retrieve the text of a blog post at the URL /post?id=${id}, where id is a prop passed to it.

export const PostContent = ({ id }) => {
  const [ text, setText ] = useState("")

  useEffect(() => {
    fetchPostContent(id)
  }, [id])

  const fetchPostContent = async () => {
    const result = await fetch(`/post?id=${id}`)
    if (result.ok) {
      setText(await result.text())
    }
  }

  return <p>{text}</p>
}

Actually, what PostContent does isn’t important because we’re not going to look at it again!

We’re going to write some tests for BlogPage in our test file BlogPage.test.js. To do that, we’ll mock out PostContent so that we won’t have to worry about its implementation.

The important point is that we stub out PostContent so that our BlogPage.test.js test suite is shielded from whatever it is that PostContent does.

Here’s the mock for PostContent:

import { PostContent } from "../src/PostContent"

jest.mock("../src/PostContent", () => ({
  PostContent: jest.fn(() => (
    <div data-testid="PostContent" />
  ))
}))

Let’s break this down.

The mock is defined with jest.mock. This must mirror the corresponding import. The call is hoisted so that the import can be replaced. Jest replaces the entire module with your newly defined module. So in this case, we’re mocking out the entire ../src/PostContent file.
Since mocks are at the module level, any component you’re mocking will need to be in its own module.
The call to jest.fn produces a spy: an object that records when it is called and with what parameters. We can then test calls using the toHaveBeenCalled and toHaveBeenCalledWith matchers.
The parameter to jest.fn defines a stub value which is returned when the function is called (when the component is rendered).
Stub implementations should always be as simple as you can make them. For React components, that means a div—which is arguably the HTML element with the least amount of meaning!
It does have an attribute of data-testid that we’ll use to get hold of this specific element in the DOM.
React Testing Library argues against using data-testid where possible, because it wants you to treat your testing as if the test runner was a real person using your software. But for mocks I ignore that guidance, because mocks are by definition a technical concern.
The data-testid value matches the name of component. In this case that means it’s PostContent. This is a standard convention that I follow for all my mocks.

This is the basic form of React component mocks. 90% (or more) of my mocks look this. The other 10% have some small additions that we’ll look at in later posts.

With that mock in place, let’s write some tests for BlogPage.

Verifying that the mocked component is rendered in the DOM

describe("BlogPage", () => {
  it("renders a PostContent", () => {
    render(<BlogPage url="http://example.com/blog/my-web-page" />)
    expect(screen.queryByTestId("PostContent"))
      .toBeInTheDocument()
  })
})

This test is the first of two tests that are always required when you use component mocks. The screen.queryByTestId searches in the current DOM for a component with a data-testid value of PostContent.

In other words, it checks that we did in fact render the PostContent component.

The responsible use of `queryByTestId`

Notice that I’ve used queryByTestId. React Testing Library tries to push you away from this function on two accounts: first, it wants you to use getBy in favour of queryBy, and second, as I’ve already mentioned above, it doesn’t want you to search by test ID.

In fact, testing mocks is about the only time I use queryByTestId. I can’t think of a time that I’ve not managed to avoid using TestId variants for non-mocked components. But for mocks, its perfect: because it’s exactly that technical detail that we want to check. The user will never see this component, it’s purely there for our tests.

What we gain is the ability to have a consistent way of building mock objects: <div data-testid="ComponentName" /> is the standard pattern we can use for all mock objects.

`getBy` vs `queryBy`

getBy variants raise exceptions if they can’t match an element. In my opinion, this is only appropriate when the calls are not part of an expectation.

So if you had:

expect(screen.getByTestId("PostContent"))
  .toBeInTheDocument()

If you hadn’t rendered <PostContent /> this test would blow up with an exception from getByTestId. The expectation is never run at all!

Given the choice between an expectation failing and an exception being raised, I’ll choose the expectation any day, since it’s more meaningful to the test runner.

Unit tests, and in particular when TDD style tests, are very often about the presence of elements. For these tests I find the queryBy much more to my liking.

Verifying that the mock is passed the correct props

The second test we need checks that the right props were passed to PostContent.

it("constructs a PostContent with an id prop created from the url", () => {
  const postId = "my-amazing-post"
  render(<BlogPage url={`http://example.com/blog/${postId}`} />)
  expect(PostContent).toHaveBeenCalledWith(
    { id: postId },
    expect.anything())
})

This uses the standard Jest matchers, toHaveBeenCalledWith to ensure that the PostContent function was called with the parameters we’re expecting.

When React instantiates your component, it’s simply calling the defined function with props as an object as the first parameter, and a ref as the second parameter. The second parameter is usually unimportant.

The JSX statement <PostContent id="my-amazing-post" /> results in the function call PostContent({ id: "my-amazing-post" }).

However, it also includes a phantom second parameter that is never useful to us, so we have to account for that.

Using `expect.anything` for the second parameter to `toHaveBeenCalledWith`

The second parameter that React passes to your component is an instance ref. It’s usually unimportant to our tests, so you’ll always want to pass expect.anything() to signify that you aren’t interested in its value.

If you wanted to get rid of the expect.anything() call, you could write your own Jest matcher that passes it for you.

If you’re passing no props, just use `toHaveBeenCalled`

On rare occasions the component you’ve mocked will take no parameters. You can use toHaveBeenCalled as a simpler version of toHaveBeenCalledWith.

Understanding the basic rules of component mocks

We’ve written two tests and one mock. Here’s the important lessons that we’ve uncovered so far:

Your mock should be a spy using jest.fn and have a stub return value of the simplest component you can possibly have, which is <div />
You should also set a data-testid attribute so you can directly pinpoint this element in the DOM.
The value of this attribute is, by convention, the name of the mocked component. So for the PostContent component, its stubbed value is <div data-testid="PostContent" />.
Every mock requires at least two tests: the first checks that it is present in the DOM, and the second tests that it was called with the correct props.

Why two tests?

I’ve mentioned a couple of times that we need at least two tests. But why is this?

If you didn't have the first test, to check for presence in the DOM, then you could make the second test pass by using a simple function call:

export const BlogPost = () => {
  PostContent({ id: "my-awesome-post" })
  return null
}

Why you would want to do this is a subject of a whole other blog post, but here’s the short version: generally we consider a function call to be simpler than a JSX statement. When you’re using strict test principles you should always write the simplest code to make your test pass.

Now what about if you had the first test, but not the second?

You could make it pass like this:

export const BlogPost = () => (
  <PostContent />
)

Again, this is the simplest production code to make the test pass.

In order to get to the actual solution, you need both tests.

This is an important difference between end-to-end tests and unit tests: unit tests are defensive in a way that end-to-end tests tend not to be.

Key point: Always write the simplest production code to make your tests pass. Doing so will help you write a test suite which covers all scenarios.

That covers the basics of mock components. In the next part, we’ll look at testing child components that are passed to your mocks.

Mocks aren’t evil! Better mocking with React Testing Library

Daniel Irvine 🏳️‍🌈 — Mon, 07 Sep 2020 20:19:31 +0000

Mocks aren’t evil!

They can help you build simpler, more resilient tests. In this series I’ll show you the patterns I use when writing React component mocks.

Here’s a quick example of a component mock. I’m using jest.mock here, which we’ll look at in more detail below.

jest.mock("../src/PostContent", () => ({
  PostContent: jest.fn(() => (
    <div data-testid="PostContent" />
  ))
}))

React component mocks don’t get much more complicated than this. The important thing is that it has a very simple stub value (the div) and a data-testid attribute that allows us to find the rendered instance very easily in the DOM. By convention, the test ID used is always the same as the component name. In this case, that’s PostContent.

Before we look at how this is used, let’s just recap what mocks are and why you might want to use them.

What’s a mock?

In the JavaScript world, the term mock is very loosely applied to mean any test double. Test doubles are simply values that replace others in your production code while tests run. They take on the interface of the object they’re replacing so that the rest of your code operates as if it hadn’t been replaced.

There are a few different reasons why you’d want to do this; we’ll cover them in examples.

If you’re curious about test doubles in general then I suggest reading Martin Fowler’s Mocks Aren't Stubs.

Jest and mocking

Jest has a function called jest.mock that allows you to mock out entire modules that you’re replacing. This is what I’m using in this guide, although there are other ways of replacing objects in JavaScript.

In Mastering React Test-Driven Development I use ES6 named module imports to create test doubles. That approaches gives slightly more flexibility but feels slightly more hacky.

The Jest page on jest.mock says that mocks ensure your tests are fast and not flaky.

While that’s true, it’s not the primary reason why I use mocks.

I use mocks because they help me keep my tests independent of each other.

To see why that is, let’s look at an example.

Why mocks?

Below is the listing for the BlogPage component, which has two jobs: it pulls an id out of a url prop and it then renders a PostContent component with that id.

const getPostIdFromUrl = url =>
  url.substr(url.lastIndexOf("/") + 1)

export const BlogPage = ({ url }) => {

  const id = getPostIdFromUrl(url)

  return (
    <PostContent id={id} />
  )
}

Imagine you’ve been writing tests for this component, and all of your tests go into BlogPage.test.js, which is a single test suite that covers both the BlogPage and the PostContent components.

At this stage you have no need for mocks: we haven’t seen PostContent yet, but given the size of BlogPage there’s really no need to have two separate test suites, since BlogPage is mostly just PostContent.

To stretch your imagination further, now pretend that both BlogPage and PostContent grow in functionality. You, being the gifted developer that you are, are adding more and more features each day.

Keeping your tests in a working state is starting to prove difficult. Each new test has more elaborate set up, and the test suite is becoming a time sink. It’s a burden to maintain.

This is a common problem, and I see it all the time with React codebases. Test suites where even the simplest change causes many tests to break.

One solution to this is to split the test suites. We’ll keep BlogPage.test.js and create a new PostContent.test.js, which should house tests specifically for behavior in PostContent. The basic idea is that any functionality that’s housed in PostContent should be specified in PostContent.test.js, and any functionality that’s housed in BlogPage (like the URL parsing) should be in BlogPage.test.js.

Fine.

But what if rendering PostContent has side effects?

export const PostContent = ({ id }) => {
  const [ text, setText ] = useState("")

  useEffect(() => {
    fetchPostContent(id)
  }, [id])

  const fetchPostContent = async () => {
    const result = await fetch(`/post?id=${id}`)
    if (result.ok) {
      setText(await result.text())
    }
  }

  return <p>{text}</p>
};

The test suite in BlogPage.test.js needs to be aware of the side effects and be ready to handle them. For example, it will need to have a fetch response lined up and waiting.

The dependency that we’ve tried to remove by splitting our test suites is still there.

Our test organization is better for sure, but nothing’s ultimately changed that causes our tests to be less brittle.

For that we need to stub out (or mock) PostContent.

In the next part we’ll look at how to do that.

Is this really necessary?

By the way, this is when you move from the realm of end-to-end tests and into the realm of unit tests.

The presence of test doubles is a key indicator that you’re writing unit tests.

Many experienced testers will immediately start new projects with unit tests (and mocks) because they know that as their codebase grows they’ll face this problem of test brittleness.

Unit tests tend to be much smaller than end-to-end tests. So small that they’re often not much more than three or four lines of code. That makes them excellent candidates for social coding practices like pair and ensemble programming.

Even when we’re unit testing, test doubles aren’t always necessary—it’s just another tool in your toolbox that you should know when and how to apply.

In the next part, I’ll look at basic mocking techniques.

Online me vs offline me

Daniel Irvine 🏳️‍🌈 — Tue, 30 Jun 2020 16:39:28 +0000

There’s a vast disconnect between the version of me that I present online and the version of me that exists in the real world.

Does anyone else struggle with this?

When I write stuff online, usually it’s about serious (and yes... boring) technical topics like unit testing and TDD. That’s only fair because that’s something I care about, have a lot of experience with, and is something I can help people with.

But it’s not who I am.

Most of my work as a software consultant is about helping people have a happier existence at work. It sounds totally ridiculous to say it like that, but it’s true.

It starts by bringing my whole self to work. My lazy, erratic and often clueless self. And I encourage others to do the same. To be themselves, and to not take their work too seriously.

And that stuff is hard to write about. Because it’s just... existence.

It’s the almost unnoticeable words and actions that happen every single day. An attitude to work and life.

Telling jokes. Laughing together. Watching YouTube videos together while you wait for the build to finish. Talking about what you got up to over the weekend... and being honest about it. Listening.

Taken on their own, these actions aren’t very interesting to outsiders. But together, they add up to something worth sharing.

This blog post is brief, but it’s a start. There will be more to follow!

🙏

When does TDD make sense?

Daniel Irvine 🏳️‍🌈 — Mon, 29 Jun 2020 12:43:15 +0000

Over the weekend, I noticed this tweet appear in my timeline:

Kent C. Dodds 🛰️

@kentcdodds

I write tests following TDD when it makes sense

00:28 AM - 27 Jun 2020

16 138

A bunch of people replied to this tweet asking: Great! But... when does TDD make sense?

Especially on the front-end, this question comes up a whole lot. Front-end programming has a legacy of being unsuited for TDD.

With that in mind, here’s a simple set of guidelines that I use to help answer this question.

If...	Then...
You’re unsure if TDD makes sense	Use TDD if you can (see below for why)
You’re working on a team	Use TDD
You’re writing static pages without behavior, like a marketing site	Don’t use TDD
Getting to market fast is more important than quality or maintainability	Don’t use TDD
You’re unsure of what you’re building	Spike first, then test later
You’re working alone on an unreleased project	Don’t use TDD
You’re working alone on a released project with users	Use TDD

Interested in why I arrived at these conclusions? Read on.

You’re unsure if TDD makes sense

With enough experience of TDD, you will understand when to apply TDD and when not.

So if you need to ask the question “When does TDD make sense?”, then TDD makes sense.

You need more experience. You need to get more practice.

Practice doesn’t necessarily mean building toy programs. Instead, find opportunities in your daily work to try TDD.

Finding ways to shoe horn TDD into your daily work practice is a whole topic itself, so, for now, I’ll suggest just this:

Start small. Next time you’ve got to add a new component to your React app, try doing it with TDD.

If you’re working on a team

TDD is a structure that helps you articulate and outwardly express ideas that would otherwise be locked in your head.

That makes it a great socializing tool for getting feedback early on your designs.

TDD goes hand-in-hand with pair programming (when you work with someone else) and team programming (sometimes called mob programming, which is when an entire team works together in front of one screen and one keyboard).

TDD can also give a speed boost to teams.

Ever experienced how slow the code review process can be?

You wait patiently for feedback and then, when it arrives, you context switch back to make the suggested changes. Then you repeat the cycle. This takes a whole lot of time and it’s mentally (and emotionally!) draining.

When you apply TDD with others, you pull that feedback process forward, which saves time later on.

If you’re writing static pages without behavior, like a marketing site

TDD is about testing behavior. Your marketing site does not have behavior.

Sure, you might want to add acceptance tests for this code, but that’s a different part of your development process.

If getting to market fast is more important than quality or maintainability

If you think following TDD will slow you down, and that in turn will lose you money and market share, then don’t use TDD. You can always come back to add tests later.

If you’re unsure of what you’re building

To “spike” is to write code without tests. Often you do this when you’re exploring a new technical domain for the first time. Spike until the point that you’re confident of the shape of your code. Then you can start adding tests.

You’re working alone on an unreleased project

If you’re building a side project that doesn’t have any users yet, and may not ever have any, then I’d avoid using TDD unless you’re specifically aiming to get better at TDD.

This can be argued two ways. On one hand you could say that TDD will delay finishing, and that translates into a risk that you will never finish.

On the other hand, you could say that without TDD you’ll end up with low quality software that risks never attaining any users because of the poor quality.

Of course, there are other ways to have a poor quality product other than simply having buggy software. You could build the wrong thing entirely: in other words, something that no one wants to use.

So for me at least, the scales tip in favor of not using TDD. Instead, you should focus on getting a finished first version ready.

However if you’re absolutely sure that your project will one day have users, and the use cases and requirements are clear, then start with TDD. It’ll save you time later on.

You’re working alone on a released project with users

The moment your side project starts attracting users, then you want to start using TDD in order to save yourself from nasty regressions.

I’d love to hear feedback if you agree, disagree, or if this was in any way useful. Go ahead and leave a comment below.

Happy coding! 🙏

React developers: TDD is not dogma

Daniel Irvine 🏳️‍🌈 — Fri, 26 Jun 2020 10:55:19 +0000

Photo by Tomek Baginski on Unsplash

——

Update: Kent replied to this article and was kind enough to explicitly tweet the following about TDD, which then provoked a great discussion from his followers. Thank you Kent!

Kent C. Dodds 🛰️

@kentcdodds

I write tests following TDD when it makes sense

00:28 AM - 27 Jun 2020

16 138

The original article is below.

——

A couple of days ago, React’s leading educator on testing wrote a tweet about test-driven development (TDD) that displayed a common misunderstanding:

Kent C. Dodds 🪐

@kentcdodds

Please don't take this the wrong way. I do know the difference between BDD and TDD and I've implemented tests in both. I just don't normally think about these methodologies or dogmatically subscribe to them.

01:22 AM - 24 Jun 2020

1 26

This is a back-handed compliment that relies on the belief that TDD is dogma (and if you read the parent tweets, also on the belief that using TDD/BDD doesn’t result in valuable tests).

I’m highlighting this because I worry that a whole generation of programmers will miss out on learning a valuable skill because of the strong words from their respected peers.

I worry that people will read this and think “Kent doesn’t use TDD, therefore TDD must be bad.”

It is also a risk to the ongoing adoption of React if the community fails to embrace an important industry technique.

Personally speaking, using TDD gave me a huge boost in my career as a software developer. Without TDD I wouldn’t be a successful independent consultant. It has helped me write high-quality Windows desktop applications in C#. It has helped me build backend monoliths and microservices in Ruby, Java and Clojure. And of course, I’ve also used it with success on the frontend: not just with React but other frameworks, with vanilla JavaScript, and with ClojureScript too.

TDD is here to stay

TDD has been around for decades and is a natural progression for developers who are interested in testing.

When you start writing tests for the first time, you are bound to make mistakes. The more mistakes you make, the more you learn about “good” testing practice. Eventually you learn about TDD, and suddenly you become slightly embarrassed about everything you did before.

TDD is anti-dogma

The TDD process is not dogma. In fact, learning to cheat at TDD is part of the fun of TDD. (But you can’t cheat until you’ve practiced the game so much that you know the rules by heart.)

TDD is disciplined. TDD says that every single line of code your write must be written with thought and care.

The reason that TDD is anti-dogma is that if you apply TDD, then you can write your code whichever way you like. Nothing is out of bounds. As long as the tests pass, you’re good.

And if the tests are passing, you’re free to refactor your code however you like.

TDD is social

TDD, combined with pair and team programming, offers a process that allows teams to combat some nefarious team problems: siloed development and overly-complex code are two that spring to mind.

TDD helps a team perform at a consistent rate. In agile parlance, people talk about consistent velocity being a sign of a high-performing team, and that’s what TDD helps teams achieve.

TDD is for beginners, too

There are coding bootcamps--like Makers in London--that teach TDD to new recruits. Group learning combined with tuition from experts is a fabulous way to learn TDD. And developers who graduate from TDD bootcamps are highly sought after because of their skillset.

Our community is full of dogma. Be careful!

The React testing community is actually very fond of dogma: Stop mocking fetch! Don’t use nested describe blocks!

To be clear, this is what dogma looks like.

One trick that has kept me well informed over the years is remembering that anytime someone tells you categorically not to do something, they are stating an opinion based on their lived experience, not fact.

Unfortunately in computing, it’s very common to see developers conflate something that is valid for their lived experience with what is valid for everyone. “This didn’t work for me, therefore it can’t work for anyone!”

The best we can do as teachers is to say: “Here is something that works for me, and here’s how I like to do it.”

I’m not asking you to use TDD

Remember that in the grand scheme of things, the React community is still an infant. It’s still learning about the world. It has much to learn from the rest of the industry.

I’m not asking you to use TDD. I’m asking you to keep an open mind.

Happy coding! 🙏

Here’s how to test arrays

Daniel Irvine 🏳️‍🌈 — Thu, 05 Mar 2020 18:13:05 +0000

If I give you a function that returns an array of objects, how do you test the returned value? How many unit tests do you need? One, two, three? What are their descriptions?

In this post I’ll show you how I do it.

It follows on from my post last week about how to test dependencies. It’s written in Ruby but it applies to any dynamic language, including JavaScript. (Statically typed languages don’t necessarily need these types of test).

Here’s how to test dependencies with mocks

Daniel Irvine 🏳️‍🌈 ・ Feb 29 '20

#ruby #testing #tdd

These posts are all about systemizing your testing.

Testing gets kind of boring once you have a system for it. But boring is good. Boring produces consistency. It means you aren’t getting stuck, or having to think too much.

Every time I have to test a returned array, I use this exact same approach.

Test 1. The right number of elements are returned

Imagine we’re testing a filter function that takes a source array of objects and a string to match on. Our tests will define the behavior of the function.



RSpec.describe "#filter" do
  let(:source) do
    [
      { id: 123, name: "Daniel", diet: :vegan, pet: :cat },
      { id: 234, name: "Danny", diet: :anything, pet: :goldfish },
      { id: 345, name: "Jane", diet: :vegetarian, pet: nil }
    ]
  end

  it "returns all elements matching the name parameter" do
    result = filter(source, "Dan")
    expect(result.length).to eq 2
    expect(result[0][:id]).to eq 123
    expect(result[1][:id]).to eq 234
  end

end

Here my test list has 3 items: you can normally prove everything with just items. No need for a longer list.

Now let’s look at how we might make that test pass.



def filter(source, name)
  source.select { |s| s[:name].include?(name) }
end

Test 2. That it returns the correct form of object

In the second test you want to ensure you test that you get all the properties that you’re expecting. Occassionally this test isn’t necessary:



it "returns all the right information" do
  result = filter(source, "Dan")
  expect(result.first).to eq source[0]
end

This test already passes, so we don’t need to write it. But if you aren’t returning the exact item from the source, then write out the value you expect instead:



it "returns all the right information" do
  result = filter(source, "Dan")
  expect(result.first).to eq({
    name: "Daniel",
    pet: :cat
  })
end

Now we actually have to write code to make that pass:



def filter(source, name)
  source
    .select { |s| s[:name].include?(name) }
    .map { |s| s.except(:diet) }
end

Test 3. That they’re in the right order

Sometimes, you care about the order that elements are returned. For this we need a new source list, again with at least three elements:



let(:unsorted_source) do
    [
      { id: 123, name: "Daniel" },
      { id: 234, name: "Dan" },
      { id: 345, name: "Danny" }
    ]
end

it "orders results alphabetically" do
  result = filter(unsorted_source, "Dan")
  expect(result[0][:name]).to eq("Dan")
  expect(result[1][:name]).to eq("Daniel")
  expect(result[2][:name]).to eq("Danny")
end

The elements must be in an unsorted order: neither ascending nor descending order. Otherwise, you could make this test pass simply by returning the same array or by calling reverse rather than sort_by.

And here’s the final result:



def filter(source, name)
  source
    .select { |s| s[:name].include?(name) }
    .map { |s| s.except(:diet) }
    .sort_by { |s| s[:name] }
end

Modification 1: Join tests 1 and 3

If I know I’m going to order my tests, I’ll join 1 and 3 together.



it "returns all elements matching the name, in alphabetical order" do
  result = filter(unsorted_source, "Dan")
  expect(result[0][:id]).to eq 234
  expect(result[1][:id]).to eq 123
  expect(result[2][:id]).to eq 345
end

Or perhaps you’d rather use map:



it "returns all elements matching the name, in alphabetical order" do
  result = filter(unsorted_source, "Dan")
  expect(result.map { |r| r[:id] }).to match_array [234, 123, 345]
end

And that’s all there is to it! 🎉

Yet another reason to prefer unit tests 😇

Daniel Irvine 🏳️‍🌈 — Tue, 03 Mar 2020 22:24:08 +0000

Have you ever gotten so frustrated when writing a unit test that you gave up and wrote an end-to-end test instead?

I think this is a common occurrence in the JavaScript world. Codebases become complex very quickly, and then (unsurprisingly) unit tests become complex too.

It seems to me that this is one reason why people prefer end-to-end tests over unit tests: because unit tests can be difficult and frustrating.

But this is precisely why unit tests are useful: unit tests give you design feedback.

If your unit test is hard to write, then that’s a good thing: the test is telling you that your design can be improved.

When you’re faced with a hard-to-write unit test, the solution is not to rewrite your test to be an end-to-end test. The solution is to refactor your production code until the unit test becomes easy to write.

A unit test is like a clamp that holds your system in place while you refactor around it.

If you’re puzzled as to what I’m talking about, then perhaps you would do well to read a book like Kent Beck’s Implementation Patterns or 99 Bottles of OOP by Sandi Metz. (And if you’re a React developer, consider reading my book, Mastering React Test-Driven Development.)

Most developers are well aware of how to make their own code simpler. And yet they don’t do it.

Very often, developers don’t have enough trust in themselves to refactor safely. They fear causing unexpected regressions. They worry that they’ll spend all day refactoring and they won’t make progress on their assigned work.

If that’s you, try giving unit testing another go. Listen to the tests and let them give you the structure you need to make positive change to your codebase.

Here’s how to test dependencies with mocks

Daniel Irvine 🏳️‍🌈 — Sat, 29 Feb 2020 14:58:16 +0000

In this post I’ll present a straightforward process for testing dependencies. No matter which language, framework or unit testing tool you’re using, you can rely on this process to fully test your dependency use.

I’m using Ruby for my code samples but they apply in just about every modern programming language.

Let’s look at an example of a class with a dependency.

class FooRepository
  def save(id, docoment)
    # ...
  end
end

class Foo
  def initialize(repository)
    @repository = repository
  end

  def do_something(document)
    @repository.save('Foo', document)
  end
end

In this example repository is the dependency. We’re going to write tests for the do_something function.

A dependency of a code unit (an object, or a function) is another code unit that is executed as part of the containing code unit’s execution.

In an object-oriented environment we often see dependencies passed into the class constructor, as in the example above. But functions can have dependencies too.

In this case, Foo does not create an instance of repository. It does not control the lifetime of the dependency. In fact, it knows nothing more about repository than these two facts:

it has a method named save that takes two arguments: a string and a document
it returns either nil or something else (we don’t care what else)

And it’s these two facts that lead our testing.

Every time we test a dependency, we need at least these two tests:

that it was invoked with the right parameters

that the return value was used correctly

Test 1: the dependency is invoked with the right parameters

This example uses some special RSpec syntax that you may not be familiar with, which I’ll explain after:

require 'foo'

RSpec.describe Foo do

  let(:repository) { spy }

  subject do
    described_class.new(repository)
  end

  it 'calls repository#save with the name and document' do
    subject.do_something(:document)

    expect(repository).to have_received(:save)
      .with('Foo', :document)
  end
end

If you’re not familiar with RSpec, here are three points that should help explain this example.

Most importantly, spy is a function call that creates a new mock object.
described_class and subject are conventional ways to refer to the subject under test. In this case described_class is Foo and subject is an instance of Foo.
More subtly, :document is a symbol that allows us to give a name to a value but we don’t care about the value itself. More on this later.

Essentially what we do is place a spy object—a type of test double which records its invocations—where the dependency should be. We then invoke the method we’re testing, and then check the spy’s records to ensure that it was indeed invoked.

Test 2: the dependency’s return value is used correctly

If you’re unfamiliar with Ruby, you may look at the code above and think that we simply throw away the return value. But this isn’t true. In Ruby, the returned value of a function is the value of the last expression, which in this case is the returned value of the call to save. There implicity behavior here that we’re relying on.

To test, we stub a return value using the allow function.

it 'returns the result of calling repository#save' do
  allow(repository).to receive(:save).and_return(:saved_document)

  expect(subject.do_something(:document)).to be :saved_document
end

Notice again that it’s not the value of the return value that’s important, but the identity. We want to check that it’s the same value we passed in. So we can use a symbol, :saved_document to do that without having to define an extra variable.

Modification 1: Protecting against dependency signature changes in dynamic languages

Imagine now that we rename the save method of repository to save_document, but we forget to update Foo: it still calls save:

class FooRepository
  # renamed from save
  def save_document
    ...
  end
end

class Foo
  def do_something(document)
    @repository.save('Foo', document) # ERROR: still calls save!
  end
end

Because Ruby doesn’t do any static analysis of our functions, our tests will still pass even though save no longer exists. This code will break at runtime.

Wouldn’t it be great if we could make our tests fail when the dependency method signature changes?

Failure/Error:
  allow(repository).to receive(:save).and_return(:saved_document)

  the FooRepository class does not implement the instance method: save

We can do that by replacing the call to spy with instance_spy, which produces a verifying double:

let(:repository) { instance_spy(FooRepository) }

This isn’t unique to RSpec: all good mocking frameworks will support this functionality.

A verifying double will break your test if you try to stub a method that doesn’t exist on the original class.

Modification 2: Add a test for every new branch

Now imagine that do_something looks like this:

def do_something(document)
  result = @repository.save('Foo', document)
  :ok if result
end

This code changes the return value of do_something depending on the returned value of save. If save returns anything, then the result is :ok, otherwise the return value is nil. Because of that, we now need two tests for the return value; one test for each branch.

it 'returns :ok when repository#save returns something' do
  allow(repository).to receive(:save).and_return(:saved_document)

  expect(subject.do_something(:document)).to be :ok
end

it 'returns nil when repository#save returns nil' do
  allow(repository).to receive(:save).and_return(nil)

  expect(subject.do_something(:document)).to be_nil
end

Systemizing testing

It’s important to systemize your testing. In this post I’ve shown you one way you can do that: every time you want to test a dependency, you can follow this process to ensure your code is correctly covered.

Testing Svelte async state changes

Daniel Irvine 🏳️‍🌈 — Fri, 28 Feb 2020 20:23:24 +0000

Here’s a short Svelte component that displays the text Submitting... when a button is clicked:

<script>
  let submitting = false;

  const submit = async () => {
    submitting = true;
    await window.fetch('/foo');
    submitting = false;
  }
</script>

<button on:click="{submit}" />
{#if submitting}
  Submitting...
{/if}

Look carefully at the definition of submit. The submitting variable is set to true before the call to window.fetch and reset to false after the call returns.

The text is only rendered when submitting is true.

In other words, the Submitting... text appears after the button is clicked and disappears after the window.fetch call completes.

Why this is difficult to test

This behavior is tricky because one of our tests will need to get into the state where the Submitting... text is displayed, and freeze in that state while our test runs its expectations. To do that we need to use Svelte’s tick function to ensure the rendered output is updatetd.

Writing the tests

We require three unit tests!

That the Submitting... text appears when the button is clicked.
That initially, no text is displayed.
That the Submitting... text disappears after the window.fetch call completes.

Testing the text appears

Let’s take a look at how we’d test this.

The test below uses my Svelte testing harness which is just a few dozen lines of code. I’ve saved that at spec/svelteTestHarness.js, and this test exists as spec/Foo.spec.js.

For more information on how I’m running these tests, take a look at my guide to Svelte unit testing.

import expect from "expect";
import Foo from "../src/Foo.svelte";
import { setDomDocument, mountComponent, click } from "./svelteTestHarness.js";
import { tick } from "svelte";

describe(Foo.name, () => {
  beforeEach(setDomDocument);

  beforeEach(() => {
    window.fetch = () => Promise.resolve({});
  });

  it("shows ‘Submitting...’ when the button is clicked", async () => {
    mountComponent(Foo);

    click(container.querySelector("button"));
    await tick();

    expect(container.textContent).toContain("Submitting...");
  });
});

Notice the use of tick. Without that, this test wouldn’t pass. That’s because when our code executes submitting = true it doesn’t synchronously update the rendered output. Calling tick tells Svelte to go ahead and perform the update.

Crucially, we haven’t yet flushed the task queue: calling tick does not cause the fetch promise to execute.

In order to make that happen, we need to flush the task queue which we’ll do in the third test.

Testing initial state

First though we have to test the initial state. Without this test, we can’t prove that it was the button click that caused the text to appear: it could have been like that from the beginning.

it("initially isn’t showing the ‘Submitting’ text...", async () => {
  mountComponent(Foo);
  expect(container.textContent).not.toContain("Submitting...");
});

Testing the final state

Finally then, we check what happens after the promise resolves. We need to use await new Promise(setTimeout) to do this, which flushes the ask queue.

it("hides the ‘Submitting...’ text when the request promise resolves", async () => {
  mountComponent(Foo);
  click(container.querySelector("button"));
  await new Promise(setTimeout);
  expect(container.textContent).not.toContain("Submitting...");
});

And there it is. Three tests to prove a small piece of behavior. Although it might seem overkill for such a small feature, these tests are quick to write—that is, once you know how to write them 🤣

Checkout out my guide to Svelte unit testing for more tips on how to test Svelte.

DEV Community: Daniel Irvine 🏳️‍🌈

Staying out of trouble

dirv / mocking-react-components

An example of how to mock React components

Stick to the patterns

What if none of the patterns works for your test suites?

Improving the testability of your code

Where to go from here

Testing multiple instances of the same mocked component

dirv / mocking-react-components

An example of how to mock React components

When that’s not enough: mock instance IDs

Yet more lessons

Verifying children passed to React mock components

dirv / mocking-react-components

An example of how to mock React components

Use expect.objectContaining to narrow down your tests

More lessons

The basic form for React component mocks

dirv / mocking-react-components

An example of how to mock React components

Verifying that the mocked component is rendered in the DOM

The responsible use of queryByTestId

getBy* vs queryBy*

Verifying that the mock is passed the correct props

Using expect.anything for the second parameter to toHaveBeenCalledWith

If you’re passing no props, just use toHaveBeenCalled

Understanding the basic rules of component mocks

Why two tests?

Mocks aren’t evil! Better mocking with React Testing Library

What’s a mock?

Jest and mocking

Why mocks?

Is this really necessary?

Online me vs offline me

When does TDD make sense?

You’re unsure if TDD makes sense

If you’re working on a team

If you’re writing static pages without behavior, like a marketing site

If getting to market fast is more important than quality or maintainability

If you’re unsure of what you’re building

You’re working alone on an unreleased project

You’re working alone on a released project with users

React developers: TDD is not dogma

TDD is here to stay

TDD is anti-dogma

TDD is social

TDD is for beginners, too

Our community is full of dogma. Be careful!

I’m not asking you to use TDD

Here’s how to test arrays

Here’s how to test dependencies with mocks

Daniel Irvine 🏳️‍🌈 ・ Feb 29 '20

Test 1. The right number of elements are returned

Test 2. That it returns the correct form of object

Test 3. That they’re in the right order

Modification 1: Join tests 1 and 3

Yet another reason to prefer unit tests 😇

Here’s how to test dependencies with mocks

Test 1: the dependency is invoked with the right parameters

Test 2: the dependency’s return value is used correctly

Modification 1: Protecting against dependency signature changes in dynamic languages

Modification 2: Add a test for every new branch

Systemizing testing

Testing Svelte async state changes

Why this is difficult to test

Writing the tests

Testing the text appears

Testing initial state

Testing the final state

Use `expect.objectContaining` to narrow down your tests

The responsible use of `queryByTestId`

`getBy` vs `queryBy`

Using `expect.anything` for the second parameter to `toHaveBeenCalledWith`

If you’re passing no props, just use `toHaveBeenCalled`