DEV Community: Ben Mitchinson

Mocking classes in Jest / Typescript

Ben Mitchinson — Mon, 18 Oct 2021 02:09:27 +0000

Cross posted on my website mitchinson.dev

TL;DR

GetANumber.test.ts mocks a class, and further customizes a class method on that mocked class for a single test.

Purpose

It was surprisingly hard to find a recently written article about the fastest way to setup Jest with some simple class mocks in Typescript. The following example demonstrates mocking a class and modifying methods of that mocked class within a single test.

Libraries like jest-ts-auto-mock are not used, cause I was unable to find a way to get them to work. Could have just been using them wrong but who knows.

I used the following methods to mock classes in an Express app while coding in test driven development.

Explanation

Comments are all over in this Example Repo, but some highlights are:

jest.mock ends up at the top of the file when it's transpiled.
- Even if you put it under other things, it gets pulled to the top.

///////////////////
jest.mock("./Class", mockOne);

it("does a thing", () => {
  expect(class).toBe(one)
})

it("does another thing", () => {
  jest.mock("./Class", mockTwo);
  expect(class).toBe(two)
})
///////////////////

// is really

///////////////////
jest.mock("./Class", mockOne); // this mock is useless
jest.mock("./Class", mockTwo); // as it's immediately replaced

it("does a thing", () => {
  expect(class).toBe(one)
})

it("does another thing", () => {
  expect(class).toBe(two)
})
///////////////////

// You might as well always write `.mock` calls at the top of your file.

The example mocks a class that's a default export. Named exports can also be mocked by nesting the class mockImplementation one layer deeper.
jest.mock('{path_to_custom_class}') will replace that paths default export in the runtime with the defined mock in __mocks__ dir defined at the same level.
If you'd like to modify a mock / assert things that happened to a mock, you need to import them from the "real" class.
- Never manually import from __mocks__, get the exports of __mocks__ "through" a normal import.

import * as MockNumberGen from "./__mocks__/NumberGen";
import * as NumberGen from "./NumberGen"; // __mocks__/CVEPathData

// Give me the mock class i've defined in __mocks__/{classname} and let me
//    name it mock{ClassName}Constructor
// Give me the mock function i've defined in __mocks__/{classname}
const { default: mockNumberGenConstructor, mockGetOne } =
  // Get these things from the NumberGen class, because I know that jest
  //     has secretly replaced it with the contents of MockNumberGen
  NumberGen as unknown as typeof MockNumberGen;
// Tell typescript that these things are really coming from MockNumberGen,
//     so it should type them as such

The full test is available here

Accenture - August + September 2021

Ben Mitchinson — Sun, 17 Oct 2021 23:51:11 +0000

Cross posted on my website

What I've worked on

Created dozens of tickets coinciding with new 2 project kick-offs.
- Feels good to organize a fresh Zenhub project board with clear acceptance criteria / patterns for completing and discussing spikes / making goals clear and accessible to the team.
- Team members expressed that they enjoyed getting to work on the initiatives because the work was made so clear.
- Velocity on these new projects is high 📈
Deployed a suite of data ingestion microservices to Azure with Helm, k8s, and Terraform
Setup Github actions to do static code analysis, image publication, and deployment with Terraform.
Setup boilerplate for a Typescript Express API with CI/CD, Linting, automatic increased VSCode support, and Jest class mocking structures / patterns

What I'd like to improve

Code Reviews

I've read the google eng practices dozens of times now. I feel like when I start a review I ask myself different questions every time, leaving me with reviews I don't feel super confident in, that are inconsistent in depth. Would like to start documenting questions I ask myself when beginning a review.

Accenture - June + July 2021

Ben Mitchinson — Sun, 01 Aug 2021 23:23:32 +0000

Cross posted on mitchinson.dev

What I've been doing at Accenture for the month of June + July.

Took a break in between jobs during the month of May. Did some contracting to deploy a small node server + corresponding frontend in AWS Beanstalk.

What I've worked on

Managed deployments in multiple AWS k9s environments with Terraform
Introduction to elixir
Learning how to work in an open source organization
Presented on code review standards + practices
Utilized the Helm Terraform provider to manage helm deployments in k9s
Configured Strimzi to deploy a kafka cluster
Pair Programming in a remote environment. We typically pair for 4+ hours a day.
Deploying Prometheus and Grafana alongside our data pipeline using public helm charts
Combining several of our teams custom helm charts into one configurable mono chart
Coming up with fun + not awkward bonding activities for our team to participate in despite our distance from one another

What I'd like to improve

Learning so much technology has left me feeling burnt out when I could be taking on new cards / tech debt. I'd like to more effectively use my time when not actively pairing.
Making new cards when discovering potential improvements
Continue to practice creating very organized and condensed technical presentations

Vail Systems - March + April 2021

Ben Mitchinson — Wed, 05 May 2021 16:25:42 +0000

Cross posted on mitchinson.dev

What I've been doing at Vail Systems for March + April.

Writing for both March and April in this post, so it's a bit longer. I spent much of the last month getting ready for a new Software Engineering position at Pillar Technologies in Des Monies, as well as working through the loss of a family member. My start date at Pillar is May 19th, and I can't wait to begin.

Currently I'm taking time off to relax + travel, as well as to do some contracting for a friend's business.

What I've worked on (Technical)

Using ffmpeg-fluent and ffmpeg to convert user-uploaded audio to universal formats. How to convert and manage codecs and conversion
Updating our application to support uploaded audio in addition to in-app generated audio. (Database -> GraphQL -> Client)
Using PlantUML as a way to communicate abstract ideas concretely, and iterate on design in a traditional code-based merge request process
Learning how to negotiate salaries, and how to respectfully exit a company
Presented on how to organize GraphQL schema inside a NestJS based application

Let GraphQL abstract the Database

Often my impulse is to have an app's GraphQL schema mirror the database 1:1. Recently, we added a new database table, and it made much more sense to instead abstract under an existing GraphQL type.

It allowed for flexibility since the resolver now would pull data from more than one database source. It helped me realize that unless you're willing to make constant changes to your schema each time the database is altered, having your schema align 1:1 with your database makes you miss out on the abstraction opportunities offered by GraphQL.

I think we could have promoted this idea by only resolving the fields that were in use on the client. We had resolvers that resolved every field of a table, even if it wasn't in use client-side. If instead, we only added fields when the need on client arose, we'd have a much slimmer + more readable GraphQL schema, and it'd be less tempting to make every database field available by default.

Using type predicates

Type Predicates are cool! Our resolver was handling two possible interfaces, and it was nice to find a type-safe way to handle either interface. Earlier in my career I would have resorted to any so it's exciting to start reaching further to see how TypeScript can help. I'd like to take an advanced TypeScript course sometime soon.

Using Type Predicates

Sometimes you can break tests

One sprint I was working on a ticket, and when I finished the AC, some existing tests broke. These broke because the ticket was part of a large new feature, and without the remaining tickets completed, tests were going to stay broken.

I assumed "don't let tests break", and took on two more tickets simultaneously, in an effort to implement all of the features necessary to make tests green.

In retrospect, I don't think this was the way to go. In the event you're merging to a feature branch and not mainline code, I think it might be okay to break tests.

If it's documented (// will be green in TTPSP-189), I think letting them fail will help code review stay small + keep the team moving faster. The expectation remains that these tests will be green before reaching mainline code, so if this
happens again, I'd like to bring it up to my team to see what they think of the approach.

What I've Learned (Personal)

Working from home -> move around the house

While I like my desk setup, I find I'm most productive when I move around the house. Room, living room couch, kitchen table. Moving around has helped my brain stay a lot more focused.

Why is the house a mess

After a day of work, I'd look at the kitchen or my room and think "why is it such a mess here", and start feeling pretty down. I was home all day, I really didn't have time to clean? I was home all day, yet there's nothing ready for
dinner?

I was at work! Of course the house is a mess, I haven't been "home", I've been at "work". Reminding myself of that line has helped me feel better when I end work for the day. Still looking forward to being at an office soon to have a
physical representation of that line.

Realistic estimates, not best case

It can be tempting for me to give "best case estimates" during standups as a way to push myself to get something done as quickly as possible. I'd like to find other ways to motivate myself that don't result in flakey estimations from my team's perspective.

Going forward I'd like to practice giving more likely estimates and working to complete them a bit sooner than originally expected, instead of finishing right down to the wire or late.

What I'd like to improve

Creating tickets for experimentation efforts

I'm privileged to be on a team where we're able to take time and experiment with new ideas. I've found that I sometimes give myself too many things to juggle: improving a Jenkins step, adding a new cypress improvement, experimenting with a new build tool. It became difficult to track all of these initiatives. I'd like to ticket ideas for refactors / features and make sure to note why I find them valuable. Then it'd be a bit more motivating to return to existing ideas during free time, instead of endlessly creating new ideas, and never completing any.

26 files changed, pump the breaks.

That's an indication that you might need to slow down and reassess your design.

Resources found / Articles I liked:

Vail Systems - Feb 2021

Ben Mitchinson — Sun, 07 Mar 2021 02:53:54 +0000

Cross posted on my website

What I've been doing at Vail Systems for the month of February.

What I've worked on

Custom theming: Account specific client theming in Material UI
Custom terminology in AWS Translate
Using Kibana to create dashboards with KQL to analyze API performance.
Using Nock with Cucumber to programmatically mock external calls
Started learning about the advantages of Snowpack and ESModules

What I've Learned (Technical)

Mocking external API calls

Nock is a great library, but I'm looking forward to
MSW growing. I'd be curious how they handle node API mocking + recording. I don't think Nock is as full of a replacement of VCR for ruby.

What I've Learned (Personal)

Break down problems into a confined example

We had an issue using decorators with nestjs modules, and in order to ask for help, I made a smaller reproducible example of the issue. This ended up being a sort of "rubber duck", and helped me arrive at the solution myself. I'd like to continue approaching problems with this style.

Company Technology Channels

Being distributed, it's hard to have conversations about specific software and tooling when I'm not sure who to talk to. I'd like to help implement specific channels dedicated to specific tools. a "cypress" channel and a "rust" channel, anything anyone can think of. This way devs can pick and choose what to be a part of, and share knowledge across teams. I suggested this and will be following up to see if there's anything I can do to help.

What I'd like to improve (Technical)

sorry-cypress

I want to investigate using sorry-cypress for better metrics + parallelization in our k8s setup. The developer experience of cypress is fantastic, but our build time is reaching an average of 30 minutes 😔

Stop reading + start trying

Often I'm reading about new tools / figuring out how something could work, but not as often do I add the dependency to a throwaway branch and experiment. I'd feel a lot more confident breaking down new technical challenges if I had previously experimented more.

What I'd like to improve (Personal)

Write as you learn

I hoped to put up two smaller blog posts about some TS examples I found interesting and wanted to share, but I can't remember half of what I wanted to note down now that it's been a few weeks. Going forward I'd like to a small technical post as I'm finishing it up.

Pace yourself (Pomodoro)

I find myself working intensely for hours, and feeling burnt out toward the end of the day. I'd like to work on restricting myself to blocks of time so that I still have the energy to take on new things at the end of the day.

Resources found / Articles I liked:

Posts of Mine

Accessing private values of a class within a method decorator

https://repl.it/@bmitchinson/decorator#index.ts

6 Months at Vail Systems

Ben Mitchinson — Tue, 16 Feb 2021 01:30:12 +0000

Cross posted from http://mitchinson.dev/Vail-2020/

In June of 2020, I started as a full-time Web Software Engineer at Vail Systems. Here are highlights of what I've learned, and what I'll be working on going forward. The plan is to do one of these a month as quick bullet points, starting in March.

What I've worked on

Our team of 5 made a full-stack app for translating text and generating corresponding audio. Large quantities of text are imported inside CSVs and then edited further inside the client React app. A NestJS API then resolves translations and audio generation with AWS services, stores resulting audio in S3, and maintains transaction data in a Vail MSSQL database.

Technology used:

React (CRA) / Yarn
Typescript (monorepo shared typings)
Node / NestJS / GraphQL
Cypress / react-testing-library
Nock / CucumberJS
DataGrip + KnexJS
Jenkins + k8s
Docusaurus

What I've Learned (Technical)

Make TDD work for you

I've found that TDD is intimidating for some developers, especially in client-side testing. I used to think that to do TDD, I had to have every single assertion down ahead of time. That's not the case. Just make a test case with a proper title, and if you're stuck, write out assertions in a comment:

// when clicked, the button will turn blue

Don't let assertions distract you from the purpose of TDD: to have a clear achievable goal while coding + making decisions. You can still fulfill that purpose without syntax perfect assertions. After writing enough tests, assertions will come more naturally.

Starting an app from scratch

I've been fortunate to start working on a product from its start and it's taught me more than I can write here, but some days I wasted time by trying to add as many new + exciting tools as possible. After focusing on core framework functionality and less added tooling, we were able to K.I.S.S (keep it simple stupid 💋). Now, we have many more options and choices for what we'd like to add when implementing new features because we're not limited by 1000x external dependencies. Shout-out to my team lead Nav for helping set those restraints.

Jenkins + Docker

Maintaining / configuring a mono repo in Jenkins with dynamic tests for linting, component + integration at both the UI and API layers, and e2e.

Auth

We implemented auth several times looking for a technology we liked. Was good to understand why auth solutions work the way they do and what they protect against (XXS, HttpOnly, Secure, Localstorage vs cookies, etc...), as opposed to just how to configure PassportJS.

What I've Learned (Personal)

Pairing remote

It's been good to practice:

giving a pairing partner space to consider a problem while on a call. It's easy to accidentally interrupt.
Working off a shared to-do list helps keep efforts focused when new ideas pop.
Gathering resources / searching online to help solve a problem, while someone is actively working on it.

Work balance while working from home

How to take a 30-minute mind break to prepare something for dinner, without it derailing your entire afternoon.
Taking breaks away from screens. Video games aren't the best break for the mind or the eyes.
How to work async: Send updates + check in on others. Grateful that my teammates are always up for a call / question.
Creating a work environment: Move your desk into a space dedicated for 9-5 and change the scenery every once and a while.
Communicate with others when struggling! It's easy to forget you're not in it alone.

Taking notes

When someone says "how do we do that again", it feels great to fire off a document / confluence page with a breakdown + meeting summary. Meetings become 2x as valuable when an artifact exists afterward, especially in a remote setting. I'm a big fan of docs and making creating documentation part of the development process.

What I'd like to improve (Technical)

Client-side performance metrics (web.dev)

We don't have metrics for many of our operations. I'd like to find ways to incorporate things like "time to interactive" and "first paint" in our test suite so that we can find regressions.

Nock

Some of our tests interact with AWS and cause conflicts when running tests on multiple branches. I'd like to work on understanding "Nock" and using it to replace AWS calls.

Docs

Areas of our app like authentication and simple things like our implementation of recaptcha would benefit strongly from a docs page. I'd like to practice writing things up on new features as they're being implemented. Instead of trying to force myself to do them after they've been completed.

What I'd like to improve (Personal)

Following through on new ideas + making tickets

Often I think "oh we could improve X by doing Y" or "Hmmm X seems like it's performing strangely". If those ideas aren't related to the task at hand, it's easy for me to throw them to the wayside. I'd like to build a better habit of making actionable tickets for those thoughts, or at the bare minimum, noting them down.

Resources found / Articles I liked:

Atlassian on Remote Work research findings - link

If it ain't broke

Ben Mitchinson — Sat, 24 Oct 2020 04:47:01 +0000

Originally posted on https://mitchinson.dev/If-It-Aint-Broke/

I haven't updated my website site in too long, and this post is somewhat of a resolution.

If it ain't broke don't fix it

Is the javascript bundle of my portfolio / blog website https://mitchinson.dev larger than it needs to be? Probably.
Am I using google analytics instead of the more ethical Plausible, yeah.
Should future static sites of mine be written in something cool lightweight and new like e11nty, maybe.
Is my lighthouse score 110%, no. (It's not toooo gross tho).

For the last view months during covid, I've had a ton of ideas. Fun things I could make / try. But at the front of my mind I say

"But first I should redo my website"

The purpose of my website is for me to be able to post projects I'm proud of and track tech related goals.

Whether the site is fully optimized to Rich Harris standards or not, it gets the job done, and it gets it done well.

While twitter is great for learning about new tools, it can be easy to be bogged
down into an endless cycle of "you should checkout and use this neat new thing".

If you attempt to use every tool designed to make launching a product "easier" and "efficiently", you'll never launch a product.

Now that the barrier of "redoing my website" has been solved with instead 50 lines of markdown, I'm looking forward to smaller more frequent posts. Hopefully hints that others can find valuable about KnexJS, GraphQL, NestJS, React and more.

I'm currently learning rust basics outside of work, to work on this VR project, and i'd love to know what you think of it.

Stay safe, wear a mask, and please vote.

Trying Lazy Loading and getting flicker?

Ben Mitchinson — Tue, 26 May 2020 02:26:55 +0000

Hey ya'll! Using suspense + lazy for the first time, would really really appreciate some help.

I've recently enabled suspense and lazy loading in my application, and when I apply them to my <Router>, I get a solid load + performance boost.

Was wondering though, in-between clicking on pages, I get this huge white flicker. I'm using it like so:

import React, { Suspense, lazy } from 'react';
import { BrowserRouter as Router, Route, Switch, Redirect } from 'react-router-dom';
{...}

const NotFound = lazy(() => import('./components/NotFound'));
const Feed = lazy(() => import('./components/Feed'));
const Food = lazy(() => import('./components/Food'));
{...}
import('./components/DEBUGEasyPeasyContents'));

const App: React.SFC = () => {
    const isLoggedIn = useStoreState(state => state.userModel.isLoggedIn);

    const Spinner = <Spin size="large" style={{ width: '100%', margin: 'auto', padding: '10%' }} />;

    return (
        <>
            <ReactNotification />
            <Router>
                <Suspense fallback={wrapHOC(Spinner)}>
                    <Switch>
                        {isLoggedIn && (
                            <>
                                <Route path="/login" exact={true} component={Login} />
                                <Route path="/changePassword" exact={true} component={wrapHOC(ChangePassword)} />
                                <Route path="/account" exact={true} component={wrapHOC(AccountInfo)} />
                                <Route path="/dashboard" exact={true} component={wrapHOC(Dashboard)} />
                            {...}
                    </Switch>
                </Suspense>
            </Router>
        </>
    );
};

export default App;

In-between clicking on pages, the whole page flashes white for like 1.3ms according to the chrome screenshot inspector. It ruins the performance boost for me, so I'm desperate to figure out the cause.

Any advice appreciated, thanks!