DEV Community: Cathy Casey-Richards

Testing Redux Selectors with resultFunc

Cathy Casey-Richards — Wed, 12 Jan 2022 15:16:28 +0000

Over the years, as I've been using Redux, I've tried quite a few different forms of testing. Actions, reducers, sagas, selectors, some with more boiler plate results than others. One of the evolutions of testing that I've enjoyed the most has been with the library I use for selectors, reselect.

When I initially started testing selectors, I was mocking out entire state trees. This is pretty simple when your selector is interacting with a tiny subset of state, but can be much more difficult as your state tree grows.

In this example, I have a simple selector I'm using to turn an array of strings into an array of objects with a value & label.

import { createSelector } from 'reselect'
import map from 'lodash/map'
import { selectToDoListItems } from '.'

const selectFormattedToDoListItems = createSelector(
  selectToDoListItems, // state.todo.items
  items => map(items, item => ({
    label: item.toUpperCase(),
    value: item,
  })),
)

export default selectFormattedToDoListItems

So how can I go about testing this?

Option 1 -- Testing via state tree

Since I know that the selector selectToDoListItems is pulling from state.todo.items, I can mock out what my relevant state tree looks like, and pass this into the function.

const state = {
      todo: {
        items: [
          'write blog post',
          'walk dog',
          'take out trash',
        ],
      },
    }

We then write out our expected result from this selector and test it. The entire block looks something like this:

import selectFormattedToDoListItems from '../selectFormattedToDoListItems'

describe('selectFormattedToDoListItems', () => {
  it('returns the items from a todo list', () => {
    const state = {
      todo: {
        items: [
          'write blog post',
          'walk dog',
          'take out trash',
        ],
      },
    }
    const expectedOutput = [
      {
        label: 'WRITE BLOG POST',
        value: 'write blog post',
      },
      {
        label: 'WALK DOG',
        value: 'walk dog',
      },
      {
        label: 'TAKE OUT TRASH',
        value: 'take out trash',
      },
    ]

    expect(selectFormattedToDoListItems(state)).toEqual(expectedOutput)
  })
})

This can be a simple solution for a small state tree, but if your state tree is large or your selector is utilizing many other complex selectors, managing a mock version of your state tree can be frustrating and brittle.

An Alternative -- `resultFunc`

The pattern I have gravitated towards over the last couple of years is using reselect's built in testing option resultFunc. Utilizing this function, we can pass in exactly the data format we are looking for. No matter if we are using a selector that has manipulated our state tree, we can simply mock out exactly what the inputs of our selector will look like. Using our above test as an example, updating it to use resultFunc looks as follows:

it('returns the items from a todo list using resultFunc', () => {
    const items = [
      'write blog post',
      'walk dog',
      'take out trash',
    ]
    const expectedOutput = [
      {
        label: 'WRITE BLOG POST',
        value: 'write blog post',
      },
      {
        label: 'WALK DOG',
        value: 'walk dog',
      },
      {
        label: 'TAKE OUT TRASH',
        value: 'take out trash',
      },
    ]

    expect(selectFormattedToDoListItems.resultFunc(items)).toEqual(expectedOutput)
  })

Notice the change in the parameter of the expect statement. This cuts down on our need to mock out the state tree exactly as designed, since we can instead pass in a replica of the relevant data.

The bottom line

Ultimately, these are both viable ways of testing selectors. Where I find resultFunc to be especially useful is in cases where the selector I am testing is utilizing other selectors that manipulate data in a way that would require the mock data I create to effectively reimplement the adjacent selectors. In future articles, I will demonstrate this via more expansive examples.

Thanks for reading out my article, and if you are inclined, check out my favorite Git client GitKraken! Use this link for a chance to win a $100 Amazon gift card :)

Intro to React Select pt. 1

Cathy Casey-Richards — Sat, 26 Jun 2021 19:17:11 +0000

Today is the first part of my series on React Select. This intro is perfect if you are completely new to React Select or React in general.

Setting things up

I started by setting up a base project using create-react-app. I called my app "demo-app".
npm create-react-app demo-app

Once my app is ready to use, I installed React Select and got to work!
npm i --save react-select

Utilizing React Select

Now that I have React Select installed, I can begin to use it by importing it and referencing it.

Adding Options

Next, we can add an option to the select in the format of:
{ value: 'value1', label: 'Label 1'}

Now that we have a simple implementation ready, I used GitKraken to view & commit my changes.

And there you have it! Keep an eye out for my follow-up articles that show you more advanced usages of React Select.

You can view of video walkthrough of this on YouTube!

Mentoring at Any Level

Cathy Casey-Richards — Wed, 29 Jul 2020 18:17:12 +0000

This article was originally published on Ocelot Consulting's Insights page.

In my first software position post-college, I was a new developer in a program focused on teaching & training new developers how to build software in the “real world”. This opportunity was incredibly beneficial to the advancement of my skills and helped shape me into the developer I am today. Years later, I would go on to be a mentor for this same program, now teaching a new group of developers how to build software in an industry environment. The main focuses of my job were to build products with my team and teach them what it means to write sustainable code while successfully implementing useful features. I found it incredibly exciting to watch the faces of those around me when something I was explaining or demonstrating really set in. Communicating technical concepts to others can be challenging on multiple levels, but that “eureka” moment makes it all worth it. This relationship with my team was mutually beneficial though, as I taught them what I knew, and they taught me my blind spots. They pointed out questions I hadn’t asked about technologies I used everyday, and they showed me the value of a completely fresh perspective.

When I’ve had conversations in the past with others about mentoring, usually some variation of the following theme comes up. “I’m not an expert” or “I don’t think I know enough”. This is one concept I can both completely relate to and also think should be 100% dismissed from your mind. Being an “expert” does not necessarily make you the best at communicating information about a subject, and is it really fair for any of us to expect ourselves to know everything before passing that knowledge on?

In 2017, I co-taught a CoderGirl class on Swift when I had just a few months of experience with the language. This is not to say that I was some sort of “expert” on Swift right away; I certainly wasn’t, but my ability to bring the perspective of learning a language as a newbie in that language was valuable. I was teaching people who were brand new to Swift; a position I had been in just a few months prior. I could use this level of understanding to communicate concepts in a way that made sense to someone just starting out.

Mentoring others, no matter your experience level, is bound to be beneficial in more ways than one. You may initially see this as an opportunity to educate others, and that should always be the goal, but it’s worth acknowledging the ways teaching others can strengthen your own skills. Every opportunity I’ve had to teach another person something, whether it be over the course of several months or simply an hour, has added depth to my abilities.

If I learned anything from my time in various roles as a mentor and teacher, it’s that I will never have all the answers. I wouldn’t want it any other way.

Where do you get your tech news?

Cathy Casey-Richards — Fri, 14 Feb 2020 02:53:46 +0000

Personally, I pull from a mix of DEV articles, tech-specific podcasts, r/programming, Twitter, and more.

I’m constantly looking for new ways of broadening what I’m exposed to, and so I’m curious! Where do you get your tech news? Are there certain creators you trust more than others? Do you have a specific avenue you choose if you only have time for one?

Are you participating in GitHub's Game Off 2019?

Cathy Casey-Richards — Mon, 04 Nov 2019 01:48:27 +0000

GitHub's annual game-focused hackathon, Game Off, is officially underway! This year's theme is Leaps and Bounds, which is open to interpretation and can be applied to many aspects of game design. The event runs throughout the entirety of November, with contributors being given the option to work on games individually or as a team.

Are you planning to participate? Do you have a game idea in mind? Let me know in the comments!

What are you excited to learn next?

Cathy Casey-Richards — Sun, 27 Oct 2019 20:25:48 +0000

As developers and technologists, we are constantly exploring new tools and languages. The constant learning process and exposure to so many different technologies and styles of creating is a large part of what makes me passionate about Software Development. So, this week, I want to ask:

1. What are you excited to learn next?

2. What interests you about it?

Personally, I have been exploring Go. I am curious about its popularity and interested to compare it to some of the languages I use now.

Discussion: Do you have a mentor?

Cathy Casey-Richards — Sat, 19 Oct 2019 23:54:11 +0000

I've been thinking a lot about how mentor/mentee relationships develop, and I have some general questions I'd like to ask the community.

For those of you who have a mentor:

How did you find this person?
How did you build this relationship to where they became your mentor?
Is this someone you work with?

For those of you who do not have a mentor:

Have you had one in the past?
Do you wish you had one?

General questions

What do you look for in a mentor?

Quick Tips for Contributing to Open-Source

Cathy Casey-Richards — Sun, 13 Oct 2019 03:33:06 +0000

We are already almost halfway through Hacktoberfest! Have you signed up for the challenge? How far along are you in progressing towards 4 PRs?

If you’ve never contributed to open-source software before, it can be tough to know where to start. There are countless repos out there being maintained by one, a handful, or even dozens of strangers. So where do you fit in? Here are a few tips to help get you rolling:

Think of the libraries & tools you actively use

The easiest place to start is with tools you are familiar with. Since you already know the functionality of a given piece of software, you can use your own experience with it to fuel ideas for ways to contribute. Are there quirks to this tool you’d like to address? Is there a feature that would make this library even more useful?

Expand the docs

If you’ve ever been reading through the docs of a library and thought “this is so hard to understand!” or “did we skip a step?”, chances are it could use some improvements. This is a common problem, as the people writing these docs are generally also the people intimately familiar with the code & functionality, which can make it tough to see holes in explanations firsthand. This is a perfect place for a user (such as yourself!) to dive in and enhance the docs.

Maybe some additional screenshots would help with clarity. Perhaps a more in-depth explanation would be really beneficial. It could even be that the docs just need some typo/grammar fixes. All of these can be invaluable (and often overlooked) additions.

Sort by certain tags

The “good first issue” tag can be useful when searching for small items to take on that were specifically curated to be newbie-friendly. The “hacktoberfest” tag is also very popular at the moment and can help you find repos where maintainers are actively looking for the help of others during Hacktoberfest.

Try out sorting through the issues marked as “bugs”. Not every contribution has to be a complex feature. Looking for opportunities to fix bugs will help you get an understanding of the existing code base and add value to the current features of the tool.

No contribution is too little

Don’t worry that the PR you want to submit is insignificant. Many of the people maintaining & enhancing open source software are doing this in their free time and will appreciate any help you are willing to give. As long as you see the value in the change you are submitting, you should feel confident that it is worthy of a PR.

Communicate

When working on an open-source tool (often in tandem with people you’ve never met before), it can be easy to forget the importance of communicating your plans & work. If you decide to take on an open issue, post a comment in the thread stating your intention to work on this particular issue so someone else isn’t duplicating the work. If you’re planning to add a new feature or enhancement, you could open an issue and give others a forum for adding feedback, suggestions, or even expressing their own desires to collaborate with you on that issue. Remember to ask for clarification where you need it. When you’re ready to submit your PR, include a useful message explaining the changes you made and the added value to the tool.

Hope this helps! Happy hacking 🎉

Tutorial: Using AWS Amplify to deploy your website

Cathy Casey-Richards — Sun, 06 Oct 2019 02:38:40 +0000

AWS Amplify is a tool for developing and deploying web and mobile applications. In this article, we’ll be focusing on the deployment capabilities of AWS Amplify and how you can use this tool to quickly & securely deploy a website.

For connecting your app to Amplify, there are multiple Git repo options or you may choose to build your own artifacts and manually upload when deploying. For this example, we’ll use GitHub.

You will be prompted to authenticate with GitHub and allow Read Access for Amplify to listen on pushes to a given branch and pull from your repo to kick off a build. Once you’ve successfully authenticated, you can select which repository & branch you’d like to deploy. Keep in mind that Amplify will automatically rebuild anytime you push to the branch you've selected.

In the next step, you’ll be asked to configure build setting for this application. If you’re using Node.js, your build spec may be as simple as the following:

version: 0.1
frontend:
  phases:
    preBuild:
      commands:
        - npm ci
    build:
      commands:
        - npm run build
  artifacts:
    baseDirectory: build
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

Once you’ve customized your build spec, you can proceed to the next step and deploy your application! This should take just a few minutes depending on how complex your build is, and then your app will appear in the Amplify console.

Here, you can see the information for the last deployment, including build status, build output, and a link to where your app is being hosted.

And there you have it! Your web app is now deployed and waiting to be rebuilt whenever your changes are ready.

Your commit messages matter more than you think

Cathy Casey-Richards — Sun, 29 Sep 2019 01:47:54 +0000

You’ve just finished up a big chunk of code, you run your tests, and you’re ready to push it out the door. In your haste, you type up a quick message and think “this is good enough”. A few weeks later, you’re scanning back through your commits looking for a certain change, and you find yourself more often than not having to glance through the code changes of each commit to figure out what that change was really doing. If this sounds familiar to you, you may want to be more reflective with each commit message and think about what you really want to convey.

Here are a few reasons why you should spend a few more moments on that commit message:

1. You likely won’t remember your changes as clearly as you think you will

You may be saying to yourself “These changes are pretty straightforward. I don’t really need to describe what’s happening here.” But in the future, when you weren’t just dabbling in that portion of the codebase minutes before, you may find it more difficult to remember what you were trying to accomplish with those changes. By simply spending a few moments to write a more descriptive commit message, you may save your future self the time (and headaches) that you may have otherwise had to spend figuring out what you were doing in a given commit.

2. Your teammates should be able to easily understand your changes

While I also strongly recommend having easy-to-decipher & self-documenting code, it is important to give the context of why you are making a change. Your teammates will likely want to glance through your code to understand the code changes more in depth, but having that first bit of context before diving in is invaluable.

3. Easily find where a bug may have been introduced

By reading a clear commit message, you should be able to easily recall what change was introduced. If you find a bug in your app related to a certain piece of functionality, you can review the changes made to that portion of the app and more easily narrow down where something may have gone awry.

4. You may need to rollback to a given commit

In the event of an app change that needs to be reverted, commits can be used to determine the last time the app was in a desirable state to roll back to.

5. You may want to find code from specific changes

Even if you don’t plan to rollback to this given commit, you may be looking for a way in which you solved a given problem in the past. If you aren’t able to piece together all of the changes made for a certain feature just by looking at the current incarnation of the code (or would prefer the efficiency of a Version Control System visually presenting these changes), you can view the contents of a commit to neatly see how those changes were implemented.

I’m not arguing for long, verbose commit messages (because let’s be real — no one wants to read a commit message longer than a sentence or so), I am arguing for being purposeful and concise in our commit messages. As a good rule of thumb, try to write your commit messages so that they take no more than 30 seconds for your audience to both read and understand the change.

What are your thoughts on the importance of commit messages?
Let me know in the comments 🎉