DEV Community: Devin Fitzsimons

Testing state machines when loading from context

Devin Fitzsimons — Tue, 07 Dec 2021 00:00:00 +0000

Testing services from context in XState

Jump to example

I'm using XState these days for personal projects. I've also been advocating it's usage at work for an extremely complex form. XState is super cool and I'm really enjoying learning and working with it. For whatever reason, the patterns make more intuitive sense to me than something like Redux. For my side project, I'm trying using some similar patterns that I might implement at work. This allows me to test out potential patterns, which is great! The downside is that occasionally, I end up using a pattern that's slightly more complex just because I know that I'll need to cover that scenario at work. In this case, it's a test but I learned how to handle testing some state from a parent context in React. It's pretty cool!

One tremendous advantage of XState is that it has a very active community. The discord bops. There's a lot of chatter, they have weekly office hours... all in all, if you're looking to pick up a state library, it seems pretty smart to pick this one.

For the setup, let's imagine an app that stores Customers in a database and when you visit /customers you have a list of where you can do lots of actions on those customers, like send a message, assign them a subscription, create a customer and edit their details. That complex page, where you can do lots of actions on a list, is a pretty good place to use a state machine. So our /customers page is something like this:

// pseudo component structure
<>
  <AddCustomer />
  <CreateAndAssignSubscription />
  <BulkMessageCustomers />

  <ListOfCustomers>
    /* there would be many of these potentially, each one responding to some
    send events and a loading message if we're loading customers */
    <DraggableCustomerCard>
      <CustomerInfo first={customer.fname} last={customer.lname} />
      <AssignCustomerSubscriptions />
      <MessageCustomer />
      <AddCustomerToBulkList />
    </DraggableCustomerCard>
  </ListOfCustomer>
</>

Crazy right, theres a draggable list, you can do lots of actions... Plus every customer is loaded on this page! This is the kind of situation you might want a state machine for as it gives you lots of visibility into all this complexity.

The problem

In this case we don't want our /customers url to load "customers" each time that we land on this URL. We'll want to load that in the background and keep it in context. So that's one state machine there, and then we have another for all the complex dragging and editing. This is super straightforward to implement and there's a super example in the XState docs that is pretty similar. So now the above component has a hook implementation like:

export default function Customers() {
  const [state, send] = useMachine(draggableCustomerMachine);

  const { customersService } = React.useContext(CustomersContext);
  const [customersState] = useActor(customersService);

All the trickly complex stuff about the draggableCustomerMachine is wrapped up nicely in it's own state machine, and the more straightforward load a list of customers work, is in context! This is great. Thanks XState team for exposing this example. But how do I test it!

For the context related portion of this, we really only want two tests.

it('renders the loading message when the CustomersContext is loading', () => {});

it('renders customer cards when the CustomersContext is loaded', () => {});

We'll make a setup function because that's my preferred pattern. Our setup function will have a default object that covers the only two things that we "actually" need for this test.

  const setup = (
    customerMachineState = { loadingState: 'loading', customers: [] }
  ) => {

First we'll force our customersMachine into the state we need for our test.

// you'll need to (import { State } from "xstate";) at the top of the file.

const testState = customersMachine.resolveState(
  State.from(customerMachineState.loadingState, {
    customers: customerMachineState.customers,
  })
);

Our state is now created, and it's pretty flexible since we can override it in our setup function if we need to. We can interpret the state next

// we'll need (import { interpret } from 'xstate';) for this part

const testService = interpret(customersMachine).start(testState);

Finally, we'll wrap our render component in the provider.

render(
  <CustomersContext.Provider value={{ customersService: testService }}>
    <Customers {...props} />
  </CustomersContext.Provider>
);

Now we can update the state returned from the provider any time we need to for a unit test! We can now update our setup functions with

  // the first one
  it('renders the loading message when the CustomersContext is loading', () => {
    const customerMachineState = { loadingState: 'loading', customers: [] };
    // rest of test

  it('renders customer cards when the CustomersContext is loaded', () => {
    const customerMachineState = {
      loadingState: 'loaded',
      customers: [{ fName: 'David', lName: 'Khourshid' }],
    };
    // rest of test

Complete example

import { render } from '@testing-library/react';
import {
  CustomersContext,
  customersMachine,
} from '../context/customersContext';
import { State, interpret } from 'xstate';

import Customers from './customers'; // the page we're testing

describe('<Customers />', () => {
  const setup = (
    customerMachineState = { loadingState: 'loading', customers: [] }
  ) => {
    const testState = customersMachine.resolveState(
      State.from(customerMachineState.loadingState, {
        customers: customerMachineState.customers,
      })
    );
    const testService = interpret(customersMachine).start(testState);

    const R = render(
      <CustomersContext.Provider value={{ customersService: testService }}>
        <Customers />
      </CustomersContext.Provider>
    );

    return R;
  };

  it('renders the loading message when the CustomersContext is loading', () => {
    const customerMachineState = { loadingState: 'loading', customers: [] };

    const { getByText } = setup(customerMachineState);

    expect(getByText(/Loading/i)).toBeInTheDocument();
  });

  it('renders customer cards when the CustomersContext is loaded', () => {
    const customerMachineState = {
      loadingState: 'loaded',
      customers: [{ fName: 'David', lName: 'Khourshid' }],
    };

    const { getByText } = setup(customerMachineState);

    expect(getByText(/David Khourshid/i)).toBeInTheDocument();
  });
});

DynamoDB Stream use cases

Devin Fitzsimons — Fri, 17 Sep 2021 15:10:48 +0000

This week, on Twitter, I asked the following question:

I don't really understand @dynamodb streams. I need a use case that makes sense to me, so maybe a web app. What kinds of actions are best for this idea. Reporting services make sense, send an action after an 'update'. But beyond that, I need a reason that this is a cool.

This came up because I'm reading The Dynamo DB Book by Alex DeBrie. The book is fantastic and I'm learning a lot, but he is very enthusiastic about streams, and I didn't see any obvious use cases. The tweet had a bunch of replies so I'll try to note them here.

I'd just rather read this on twitter

View the actual tweet

Highlights

One response by @astuyve was a super helpful thread. The example that made the most sense for me was Twitter for Pets. Check out that whole thread here
Another helpful post showed a web app example on Amplify(actually from dev.to). You can check out the post here and follow @mtliendo who is pretty great!
This helpful youtube talk was mentioned by @edjgeek

Who to follow from this tweet

@astuyve, @mtliendo, @ryands1701, @filmaj, @sachinpc, @barney_parker, @danilop, @edjgeek, @NoSQLKnowHow, @MorgantWillis, @edelman215, @pier_sf

Final thoughts

I'm still getting comfortable with Dynamo and improving my understanding of Single Table Design, Streams, and all things Serverless. But, the amount of resources and folks that are willing to chat about how this works is pretty awesome.

Helpful setup function patterns for testing

Devin Fitzsimons — Wed, 07 Jul 2021 00:00:00 +0000

How a setup pattern can simplify testing components

I ran into this pattern at work, and I love it. It makes tests straightforward to read. This way, each test, is only testing one prop at a time, and the setup is ultra-clear. If you're updating a single prop, the test itself declares that. Let's imagine the following component (stolen from the footer of my personal site but simplified).

The goal will be to have a component that renders three links, and a view more button, or more than 3 links and, a show less button.

import React from 'react';

const Footer = ({ links }) => {
  // handles the number of links to show  
  const [linksLength, setlinksLength] = React.useState(2);
  // handles the button text
  const buttonText = linksLength === 2 ? 'View more' : 'View less';
  // handles the links to show, if the number > 2 it 
  const socialLinks = links.filter((item, index) => index <= socialLength);

  const handleClick = () => {
    setSocialLength(socialLength === links.length ? 2 : links.len)
  }

  return (
      <div>
        <h4>Site Links</h4>
        <ul>
          {socialLinks.map(({ siteLink, siteName }) => 
            (
              <li key={siteLink}>
                <a href={siteLink}>
                  {siteName}
                </a>
              </li>
            ))}
        </ul>
        <button onClick={() => handleClick()}>{buttonText}</button>
      </div>
    )

There are a million ways to write that but suppose that's how we did it. I'd write three tests to write for this I think.

toggles button text between "view more" and "view less"
three links are rendered by default
more than three links are rendered on click
maybe a 4th for no button when there are fewer than 3 links

With the setup function this test looks something like this:

describe('<Footer/>', () => { // this is a style I like just preference
    const setup = overrides => {    
      const props = {
      links: ['link-one', 'link-two', 'link-three', 'link-four']
      ...overrides
      }

      const R = render(<Footer {...props}/>)

      return {
      ...R,
      props
    }
  }

  it('toggles button text between "view more" and "view less"', () => {
    const {
      queryByText, getByText, getByRole
    } = setup();

    expect(getByText(/View more/i)).toBeInTheDocument();
    expect(queryByText(/View less/i)).not.toBeInTheDocument();
    userEvent.click(getByRole('button'));
    expect(getByText(/View less/i)).toBeInTheDocument();
    expect(queryByText(/View more/i)).not.toBeInTheDocument();
  })
})

Generally, I'm weakly opposed to multiple expects in a block but that case makes sense.

Next we handle showing the default.

  it('shows three links by default', () => {
    const mockLinks = ['One', 'Two', 'Three', 'Four'];
    const { queryByText } = setup({links: mockLinks});

    expect(queryByText(/Four/i)).not.toBeInTheDocument();
  })

For me, this test is super clean. I can know everything important about this inside the "it block".

I suppose some folks would dislike this next test since it's basically the same. Reasonable arguments could be made about duplication, or perhaps how you don't need to have a test that tests super similar things. I like this test duplication.

  it('more than three links are rendered on click', () => {
    const mockLinks = ['One', 'Two', 'Three', 'Four'];
    const {
      queryByText, getByText, getByRole
    } = setup({links: mockLinks});


    expect(queryByText(/Four/i)).not.toBeInTheDocument();
    userEvent.click(getByRole('button'));
    expect(getByText(/Four/i)).toBeInTheDocument();
  })

Look how clean! One thing to note here is that I'm getting by role button. A few months ago I would have used a getByText(/View more/i) for that. But suppose marketing decides they want to change that to Show more. Your test, for how many links show, fails. It's a little thing, but I think it's nicer. Also, it forces you to make a small react component, rather than some 300 line monstrosity.

If we want, we can add that fourth test (which would fail if we don't fix the example code).

  it('shows no button when there are fewer than 3 links', () => {
    const mockLinks = ['One', 'Two'];
    const { queryByRole } = setup({links: mockLinks});

    expect(queryByRole('button')).not.toBeInTheDocument();

    // This is also okay I just wouldn't do it now
    // expect(queryByText(/View more/i)).not.toBeInTheDocument();
  })

This simple little pattern has been helpful for me. I typically write more testable code because of this setup function. I'm glad I learned it and it's useful for me. If it's you're kinda thing, you can use this extension. It's not particularly fancy but I made it to make that easier for myself. Maybe it helps you. Message me if this makes sense or you have some other testing tips. I think testing is probably my favorite part of writing code these days.

Aristotle, Vampires, and Learning to Code

Devin Fitzsimons — Sat, 01 May 2021 00:00:00 +0000

Eating people is gross until it's not

My wife decided to learn to code. Therefore, I'm an observer of a person who is learning to code. This proximity means I reflect a lot on my learning. That leads me to think about vampires. LA Paul asked the question, how should a person decide to become a vampire? If I'm honest, it took me about a year to understand the question. The crux of it, I think, is that becoming a vampire means you'll experience a world so fundamentally different, that the questions you asked yourself before becoming a vampire, aren't really meaningful anymore. I don't think this is discussed enough in the learn to code section of the internet. Learning to code is a non-stop series of viewing the world from different angles and reimagining your relationship to computers. Let's consider:

mkdir some-project
cd some-project
yarn
yarn test

None of those steps are even learning to code, but understanding each one means you understand how to interact with a computer in a way that's wholly different than before. That has some awesome consequences. At first, a text editor is slow, then once you've been a developer for a while, copy-pasting in a word doc feels slow and text editors are fast. It's borderline impossible to go back. You've now become a vampire, especially if you learned Vim.

When you're learning to code, the mental jumps can be pretty profound. There's syntax, computer file systems, some networking, browsers, the entire concept of terminals and ports. Add to this list that there are ancillary systems like git, Github, deployment processes, AWS. As you're learning each one of these things the next becomes more understandable, relevant, and powerful. Before you know it, they're all one interconnected system. Meanwhile, you're just trying to get your mind around what an array is and why it doesn't start at one. When you have the opportunity to watch someone else learn to code keep an eye out for tunnel vision. I'm lucky enough to see it in action. I'd wager when I'm problem-solving one of my biggest problems is focusing on just one thing, rather than the range of issues that might be happening. This is in part because I don't know what the range of problems might be.

This makes me think about chess

I'm not particularly good at chess. I have the chess.com app so I'm better than some, but I'm just realizing that you don't think moves ahead, but rather, you think about territory. I imagine the best chess players don't even think about territory. When you're first learning chess you need to think about the moves. That's a fundamental part of how chess works. Coding works similarly.

const bishop = new ChessPiece('Bishop');

There's a lot there. Just understanding the syntax here is tremendous. The next leap here is understanding that a bishop might be an abstraction of a Piece that has moves or points. Then, that same bishop lives inside a board class. When you decide to learn to code though, did you decide to choose to understand an abstraction like Classes. Or that functions can be chained on each other? Breaking down a concrete thing like a chess piece is a reimagining a game. It's also pretty interesting that you can break the game down, and not understand, how that game works. This is what my wife is learning.

Currently, I'm learning that abstraction is folly. What a twist! In 3 years perhaps I'll realize that abstraction was the right thing all along. One of my favorite parts about unit testing is how deliberate it can be. Explicitly walking yourself through some code and saying, this function returns an array. Perhaps unit tests are thinking a move or two ahead in chess. What makes a good unit test though, is it documenting a part of a code-base? I've yet to experience that but people say it. I suppose someday, I'll see tests as documentation. Maybe I'll restructure my testing strategy to document the code, rather than simply document the inputs and outputs? Maybe that's the coding equivalent of territory in chess.

What about Aristotle though?

I don't know a lot about Aristotle. Apparently, he spent a lot of time thinking about chair and yellow. A chair is a thing, yellow is a thing. A yellow chair is also a thing. Or is it two things? The idea that something can be two things, or one thing with two properties is pretty profound. The word on the street is it's a fundamental insight in philosophy. It certainly is in coding. Something can have properties and values and be multiple things at once. It's like the first time you realize that front ends are just collections of divs on top of divs. When you're learning to code, first you have to learn that a chair is a chair, it's yellow, and you can control it, and make it something else.

I'm not exactly sure that I signed up for that insight when I decided to code. I learned to code for the money. Not because I love it or I like puzzles. Now I'm here and I'm watching my wife. I'm a different person than before. For lots of reasons, but certainly ,because I look at things like a developer now. The same thing is going on for my wife right now. She's practicing reduce statements in the other room. In six months she'll be thinking about how a state machine is a better way to have insight into what's happening in an application. Each practice problem she gets the syntax get's easier, and the ability to imagine the shape of the data gets a little easier. Before you know it, you're just writing some code because it solves the problem you're facing. This is the point of code katas right? Aristotle also thought that at some point, you should stop learning, stop with self-improvement, and get after it.

If Aristotle is correct there are two parts of life (I'll loosely equate this to learning a skill), the becoming, then the part where you are what you're going to be. At least in part, I disagree. Especially, when it comes to development. The practice of breaking down chairs into smaller abstractions of chairs, or building them up into systems that make up stadiums, I am pretty sure that's a continuous improvement process. There's a point however where a person can get a job, contribute to a team, and so on. My wife will never finish learning to code. I suspect that I failed in my duties as a friend and husband when I didn't make that clear. I couldn't make it clear though. I'm a vampire now. She's becoming one, so if I'm lucky, by the time she realizes I've made a mistake, she'll be a vampire and never know.