DEV Community: Mercedes Bernard

Jest mocking strategies

Mercedes Bernard — Mon, 13 Jul 2020 01:14:15 +0000

This post was last updated on July 12, 2020. Always refer to library documentation for the most updated information.

Note: this post assumes familiarity with Jest and mocking. If you want to learn more, take a look at the Jest docs first 🙂

ES6 Exports
- Default export of a vanilla function
- Named export of a vanilla function
- Default export of an object
- Named export of an object
- Default export of a function that returns an object
- Named export of a function that returns an object
Mock behavior
- Browser functionality
  - For the whole test suite
  - In a single file
- Node modules
  - For the whole test suite
  - In a single file
- A single function of a node module
  - For the whole test suite
  - In a single file
  - In a single test
Common mocking errors
- The module factory of jest.mock() is not allowed to reference any out-of-scope variables
- Cannot spy the default property because it is not a function
- Cannot set property of #<Object> which has only a getter
- Warning: An update inside a test was not wrapped in act

Recently, I've been spending more time wrestling with uncooperative mocks than writing the code or the tests combined. I created this post to serve as an easily navigable guidebook of strategies for the next time jest.mock('modulename') won't cut it. This is not an exhaustive list, there are multiple ways to satisfy every use case.

When mocking a module or function, there are 2 main things to consider:

How was the module exported?

What do we want the behavior of our mock to be?

All of the following code samples can be found on my Github. The sample application shows you a random cute image of an animal every 3 seconds. It's a React app with Jest as the test runner and uses React Testing Library to test the component DOM (this is the default configuration with Create React App).

Despite being built with React, the mocking examples should be easily portable to any framework.

ES6 Exports

Before we worry about our mock's behavior, it's important to understand how the package we're using is exported.

When publishing a package, the maintainer makes decisions such as choosing default or named exports and whether to export a vanilla function, an object, or a function that returns an object of other functions. All of those choices affect how the package needs to be mocked in the tests of our application code.

Below, we'll look at some tiny examples to highlight how different exports change our mock strategy.

Default export of a vanilla function

In our first example, the library exports is a single default function. When this function is called, it executes the library's logic.

export default function () {
  return "real value";
}

To mock its implementation, we use a default import, mock the module, and provide a factory (a function which will run when the module is invoked).

Because the module is a function, we provide a factory that returns the mock function we want to be invoked instead of the module. In this example, we provided a mock implementation so we could set the return value.

import example from "../defaultFunction";

const mockExpected = "mock value";
jest.mock("../defaultFunction", () => jest.fn(() => mockExpected));

it("returns the expected value", () => {
  const actual = example();
  expect(actual).toEqual(mockExpected);
});

Named export of a vanilla function

In our first example, the library exports is a single named function. When this function is called, it executes the library's logic.

export const example = () => {
  return "real value";
};

To mock its implementation, we use a named import, mock the module, and provide a factory that returns an object with the named function and its mock implementation.

This is slightly different than the previous example because of the named export.

import { example } from "../namedFunction";

const mockExpected = "mock value";
jest.mock("../namedFunction", () => ({
  example: jest.fn(() => mockExpected),
}));

it("returns the expected value", () => {
  const actual = example();
  expect(actual).toEqual(mockExpected);
});

Default export of an object

In this example, the library exports a default object that has a property for the function we want to mock.

export default {
  getValue: () => "real value",
};

To mock getValue, we use a default import, spy on the imported object's getValue property, and then chain a mock implementation to the returned mock function.

Because example is an object, we can spy on its properties. If we didn't want to mock the implementation, we could leave that part off and still be able to track that the returned mock function was called.

* Note: jest.spyOn invokes the function's original implementation which is useful for tracking that something expected happened without changing its behavior. For true mocking, we use mockImplementation to provide the mock function to overwrite the original implementation.

import example from "../defaultObject";

const mockExpected = "mock value";
jest.spyOn(example, "getValue").mockImplementation(jest.fn(() => mockExpected));

it("returns the expected value", () => {
  const actual = example.getValue();
  expect(actual).toEqual(mockExpected);
});

Named export of an object

In this example, the library exports a named object that has a property for the function we want to mock.

export const example = {
  getValue: () => "real value",
};

Mocking getValue on the named export is the same as mocking it on the default export 🥳 This is one of the few cases where the export type doesn't matter because it's an object that can be spied on.

import { example } from "../namedObject";

const mockExpected = "mock value";
jest.spyOn(example, "getValue").mockImplementation(jest.fn(() => mockExpected));

it("returns the expected value", () => {
  const actual = example.getValue();
  expect(actual).toEqual(mockExpected);
});

Default export of a function that returns an object

This example is a bit more complicated than the previous ones. Here, the library exports a default function that returns an object that has a property for the function that we want to mock. This is a common pattern to allow developers to destructure their desired function off the module function.

const { getValue } = example()

As a simple example, it looks like this.

export default function () {
  return {
    getValue: () => "real value",
  };
}

To mock getValue, we use a default import to import the entire module's contents (the * as syntax which allows us to treat the module name as a namespace), spy on the imported module's default property, and then chain a mock implementation to the returned mock function.

In this case, our mock implementation is a function that returns an object with a getValue property. getValue is a mock function.

import * as exampleModule from "../defaultFunctionReturnObject";

const mockExpected = "mock value";
jest.spyOn(exampleModule, "default").mockImplementation(() => ({
  getValue: jest.fn(() => mockExpected),
}));

it("returns the expected value", () => {
  const { getValue } = exampleModule.default();
  const actual = getValue();
  expect(actual).toEqual(mockExpected);
});

Named export of a function that returns an object

Similar to the previous example, the library exports a named function that returns an object that has a property for the function that we want to mock.

export function example() {
  return {
    getValue: () => "real value",
  };
}

Mocking this use case is very similar to the default export case above except that we need to spy on the named export rather than the default export.

To mock getValue, we use a default import to import the entire module's contents, spy on the imported module's example property (this is the named export), and then chain a mock implementation to the returned mock function.

In this case, our mock implementation is a function that returns an object with a getValue property, just like in our previous example.

import * as exampleModule from "../namedFunctionReturnObject";

const mockExpected = "mock value";
jest.spyOn(exampleModule, "example").mockImplementation(() => ({
  getValue: jest.fn(() => mockExpected),
}));

it("returns the expected value", () => {
  const { getValue } = exampleModule.example();
  const actual = getValue();
  expect(actual).toEqual(mockExpected);
});

Mock behavior

We've seen how different export strategies affect how we structure our mocks. Let's look next at how to change our mocks based on the desired behavior we want within our tests.

Browser functionality

For the whole test suite

If we are using a browser API throughout our application, we may want to mock it for your entire test suite. I reach for this strategy often for localStorage and sessionStorage.

For example, here's a mock implementation of sessionStorage.

export class SessionStorageMock {
  constructor() {
    this.store = {};
  }

  clear() {
    this.store = {};
  }

  getItem(key) {
    return this.store[key] || null;
  }

  setItem(key, value) {
    this.store[key] = value.toString();
  }

  removeItem(key) {
    delete this.store[key];
  }
}

And then in the setup file, we'll reset the global sessionStorage implementation to our mock implementation for the duration of the test suite.

const unmockedSessionStorage = global.sessionStorage;

beforeAll(() => {
  global.sessionStorage = new SessionStorageMock();
});

afterAll(() => {
  global.sessionStorage = unmockedSessionStorage;
});

While the tests run, any code that inserts/removes from sessionStorage will use our mock implementation and then we can assert on it in the test files.

it("sets sessionStorage isFetching to true", () => {
  const { getByText } = render(subject);
  const button = getByText(
    new RegExp(`please fetch me some cute ${animal}`, "i")
  );
  act(() => {
    fireEvent.click(button);
  });
  expect(sessionStorage.getItem("isFetching")).toEqual("true");
});

In a single file

If we're using a browser API, but want different behavior throughout our tests we may choose to mock it in the relevant test files.

This is helpful when we're using the browser fetch API and want to mock different responses in our tests. We can use a beforeEach block to set our global.fetch mock implementation.

We set global.fetch to a mock function and use Jest's mockResolvedValue (syntactic sugar wrapping mockImplementation) to return a mock response in the shape our code expects.

beforeEach(() => {
  jest.resetAllMocks();
  global.fetch = jest.fn().mockResolvedValue({
    status: 200,
    ok: true,
    json: () => Promise.resolve({ media: { poster: "hello" } }),
  });
});

Then we can assert that global.fetch was called the expected number of times.

 it("fetches an image on initial render", async () => {
  jest.useFakeTimers();
  render(subject);
  await waitFor(() => expect(global.fetch).toHaveBeenCalledTimes(1));
});

Node modules

For the whole test suite

Sometimes we are using a node module throughout our code and we want to mock it for our entire test suite. In this case, we can create a manual mock that Jest will automatically use during tests whenever it encounters references to that module.

In this little sample application, we're using Voca to capitalize some words in our navigation. To create a manual mock, we create a folder named __mocks__ inside of our src directory and place our mock implementation there. Note: this is counter to what the documentation says. At the time of writing, there is an open issue documenting this. The fix appears to be placing your mocks inside src instead of adjacent to node_modules.

In our mock, we use jest.genMockFromModule (or jest.createMockFromModule) to create an automock and then extend it with our mock implementation for the relevant function(s). By extending an automock, you limit how often you have to manually update your manual mock when the original module changes.

const voca = jest.genMockFromModule("voca");
voca.capitalize = (word) => `${word} capitalize mocked!`;
export default voca;

Then you can assert on the expected behavior of your mock within your tests.

it("capitalizes the current page name", () => {
  const { getByText } = render(subject);
  expect(getByText(/capitalize mocked!/i)).toBeInTheDocument();
});

In a single file

Mocking an entire node module for a single file in our test suite is not that different than what we did to mock it for the whole suite. Instead of placing our code in our setup file, we put it in the test file where we want the mocking to occur.

To mock moment in one test file, we can do something very similar to what we did for pluralize. We use a default import, mock the module, and make sure that the default return shape matches the return shape of the original implementation.

Assuming the code we want to test looks like this

export const toMoment = (datetime) => {
  return moment(datetime);
};

We would mock moment like this

import moment from "moment";

jest.mock("moment", () => ({
  __esModule: true,
  default: jest.fn(),
}));

Then we can assert that our mock moment function was called

describe("toMoment", () => {
  it("calls moment() with the correct params", () => {
    const dateParam = new Date();
    toMoment(dateParam);
    expect(moment).toHaveBeenCalledWith(dateParam);
  });
});

If we want to use some of the functions returned from Moment's default function, we need to update our mock to have mock implementations for those as well.

let mockFormat = jest.fn();
jest.mock("moment", () => ({
  __esModule: true,
  default: jest.fn(() => ({ format: mockFormat })),
}));

A single function of a node module

For the whole test suite

Just like how we may want to mock browser functionality for our entire test suite, sometimes we may want to mock a node module for our test suite instead of in individual files.

In this case, we can mock it in our setup file so that all tests in the suite use that mock. In our sample application, we mock the Pluralize module for all of our tests.

In our setupTests.js file, we mock the default export.

jest.mock("pluralize", () => ({
  __esModule: true,
  default: jest.fn((word) => word),
}));

You'll note that we have __esModule: true here. From Jest's documentation, "When using the factory parameter for an ES6 module with a default export, the __esModule: true property needs to be specified. This property is normally generated by Babel / TypeScript, but here it needs to be set manually."

In a single file

In my experience, the most common mocking use case is to mock the same behavior of one function in a node module for every test in a file. To do this, we declare mock once within the file (remembering what we know about module exports).

For example, in our sample application, we use axios.get to fetch cute pictures of dogs, cats, and foxes. When we're fetching pictures, we want to make sure our code is correctly calling axios.get. And when we're not fetching, we want to make sure we're not making unnecessary requests.

To mock axios.get, we use a default import, spy on the imported object's get property, and then chain a mock implementation to the returned mock function.

import axios from "axios";

jest
  .spyOn(axios, "get")
  .mockImplementation(() => Promise.resolve({ data: { file: "hello" } }));

And then we can assert that axios.get was called the expected number of times.

it("gets a new image on the configured interval", async () => {
  jest.useFakeTimers();
  render(subject);
  await waitFor(() => expect(axios.get).toHaveBeenCalledTimes(1));
  act(() => jest.advanceTimersByTime(refreshTime));
  await waitFor(() => expect(axios.get).toHaveBeenCalledTimes(2));
});

We can also use Jest's syntactic sugar functions to be even terser in our mocking code. The following two examples do the same thing as the mock implementation above.

jest
  .spyOn(axios, "get")
  .mockReturnValue(Promise.resolve({ data: { file: "hello" } }));

And even shorter

jest.spyOn(axios, "get").mockResolvedValue({ data: { file: "hello" } });

In a single test

Finally, sometimes we want to test different behavior within a single test file. We may have error handling or loading states that we want to mock and test that our code behaves appropriately.

In this case, we mock the function that we want with Jest's default mock, jest.fn(), and then we chain a mock implementation on it inside each of our test cases. I like to put the mock implementation in a beforeEach just inside a describe labeled with the case I'm testing, but you can also put it inside an individual test.

In our sample application code, we mock React Router's useParams hook. In our example, we're using Jest's requireActual to make sure we're only mocking the useParams function and nothing else in the module.

import { useParams } from "react-router-dom";

jest.mock("react-router-dom", () => ({
  ...jest.requireActual("react-router-dom"), // use actual everything else
  useParams: jest.fn(),
}));

And then we can set up our different use cases and assert the expected behavior.

describe("with a supported animal type", () => {
  beforeEach(() => {
    useParams.mockReturnValue({
      animal: mockAnimal,
    });
  });

  it("renders the correct animal component(s)", () => {
    const { getAllByText } = render(subject);
    expect(getAllByText(new RegExp(mockAnimal, "i")).length).toBeGreaterThan(
      0
    );
  });
});

describe("without a supported animal type", () => {
  beforeEach(() => {
    useParams.mockReturnValue({
      animal: "hedgehog",
    });
  });

  it("does not render an animal component", () => {
    const { getByText } = render(subject);
    expect(getByText(/oh no/i)).toBeTruthy();
  });
});

Common mocking errors

I find myself running into similar errors over and over when I'm writing tests. I'm sharing fixes I've found in case it's helpful.

`The module factory of jest.mock() is not allowed to reference any out-of-scope variables`

You'll see this error when you try to use variables that Jest thinks might be uninitialized. The easiest fix is to prefix "mock" to your variable name.

Not allowed

let format = jest.fn();
jest.mock("moment", () => ({
  __esModule: true,
  default: jest.fn(() => ({ format: format })),
}));

Allowed

let mockFormat = jest.fn();
jest.mock("moment", () => ({
  __esModule: true,
  default: jest.fn(() => ({ format: mockFormat })),
}));

`Cannot spy the default property because it is not a function`

You'll see this error if the object does not have a function for the property you are spying. This usually means that you're not structuring your mock properly and the module is exported differently than what you're configuring. Check out the ES6 Exports examples above to see the various ways you may need to change your spy.

`Cannot set property of #<Object> which has only a getter`

This error comes up when trying to mock the implementation for an object which has only getters. Unfortunately, I haven't found a way around this other than completely changing my mocking strategy. I run into this most often with React Router.

Spy on default export raises this error

import ReactRouterDom from "react-router-dom";
jest.spyOn(ReactRouterDom, "useParams").mockImplementation(jest.fn());

Spy on the module contents raises "property is not a function" error

import * as ReactRouterDom from "react-router-dom";
jest.spyOn(ReactRouterDom, "default").mockImplementation(() => ({
  useParams: jest.fn(),
}));

Mocking the module, requiring actual and then overwriting the useParams implementation with a mock function works.

jest.mock("react-router-dom", () => ({
  ...jest.requireActual("react-router-dom"), // use actual for all non-hook parts
  useParams: jest.fn(),
}));

`Warning: An update inside a test was not wrapped in act`

This is not a mocking error specifically, but one that catches me all the time.

If you're seeing this warning but you know that all of your code is wrapped in act(), you might be asserting on promises that haven't resolved yet. React Testing Library has a handy little async utility, waitFor, for this exact use case.

This test raises the "not wrapped in act" warning

it("fetches an image on initial render", async () => {
  jest.useFakeTimers();
  render(subject);
  expect(axios.get).toHaveBeenCalledTimes(1);
});

Wrapping the assertion in waitFor resolves the warning.

it("fetches an image on initial render", async () => {
  jest.useFakeTimers();
  render(subject);
  await waitFor(() => expect(axios.get).toHaveBeenCalledTimes(1));
});

Boxes and lines: a frugal person's UML

Mercedes Bernard — Mon, 06 Jul 2020 14:21:54 +0000

On my team, we've recently started making more diagrams before and after we write code. When we’re trying to decide a path forward, diagrams are a great way to visualize the flow of information through a system. Diagrams are also a wonderful artifact and deliverable for stakeholders and future developers. However, none of us are completely fluent in Unified Modeling Language (UML), the industry-standard way to make diagrams, and that’s ok!

Time is expensive. Learning all the subtleties of UML would take a lot of time and require your audience to do the same. Boxes and lines are all you need to create informative diagrams that everyone can understand. So let’s be frugal with our time, draw boxes and lines, and get the most bang for our buck.

What is UML?

UML stands for Unified Modeling Language and was created to define a standard visual vocabulary for specifying, modeling, and documenting systems. Its most common use case is for modeling software systems, but it can be applied to any system such as manufacturing or business processes.

UML defines 13 standard diagram types. For each type, it defines how to draw shapes and lines, how to label them, what types of connectors to use, and various other visual indicators to model structure, behavior, and interaction of a system. It outlines things such as when to use a rectangle with rounded edges vs a regular rectangle or a solid line vs a dashed line and what those differences indicate in the context of your diagram.

Unfortunately, the language specification is incredibly dense and hard to understand. From the official website, “[The UML specification is] also highly technical, terse, and very difficult for beginners to understand.” But at its core, UML is just boxes and lines.

Why UML?

If UML is so hard to learn and understand, why are we even talking about it? Having a shared visual vocabulary is incredibly valuable. I would argue that 95% of the time, we don’t need the nuance of the entire UML spec. 95% of the time, boxes and lines are the only tools we need to quickly and easily convey an idea. And by keeping things that simple, your audience is usually able to intuit your meaning.

I think a high-level understanding of just a few of the standard diagram types and when to use them is helpful. My rule of thumb is to have a preferred diagram type you can reach for in each of the 3 categories: structure, behavior, and interaction (interaction is often included as a subtype of behavior). I’ll outline which 3 I think are the most useful but you may choose a different set of 3 depending on the type of systems you work with and software development you do.

Structure diagram

When I want to model the structure of a system or part of a system, I like to reach for a class diagram. A class diagram outlines the classes, their attributes and operations, and the relationships between instances of the classes. I often cut corners with this diagram by not worrying about labeling the access modifiers on the attributes and operations. I even leave the attributes and operations out a lot of the time! 😱

The bit that I find most valuable is modeling the relationships between classes. I find class diagrams especially helpful to model composition and inheritance within more complex parts of an application. Being able to visually see those relationships provides crucial context. And don’t worry if it's hard to remember what type of arrow and line to use in a class diagram, I almost always mess it up. Modeling that there is a relationship is the important part, what the relationship is can be inferred or labeled if the arrow isn’t correct.

If you want to learn about class diagrams and how to make them, I like LucidChart’s tutorial or Visual Paradigm's guide.

Behavior diagram

When I want to model the behavior of a part of a system, I like the simplicity of activity diagrams. An activity diagram is a developer’s flow chart. It’s great for modeling step-by-step what happens in a system and visualizing the logic in your code. The nice part about an activity diagram is that you can make it as high-level or granular as you want. You could focus on the major milestones for a user request, from the frontend to the server to the database or you could focus on the steps of a single algorithm in one file in your code.

Like class diagrams, I don’t think it’s incredibly important to use a diamond to represent a decision or use the correct start and end symbols. Your audience is smart and they can understand your meaning if you focus on visually modeling the flow with just standard boxes and arrows.

Check out LucidChart’s tutorial or Visual Paradigm's guide to dig deeper into activity diagrams.

Interaction diagram

The last diagram that I always have on hand is a sequence diagram. When I want to show how data moves through a system—passing from one object to another and how the return values are interacted with by other objects—I choose a sequence diagram. Of the 3 I’ve shared in this post, this one might look the most complicated but it's extremely helpful for showing a process modeled over time. In a sequence diagram, you create a lifeline for each object in your system to show its responsibilities while it’s in use. When you read a sequence diagram, you are reading it both horizontally and vertically. Horizontally documents the control flow and vertically documents the passage of time.

As before, I don’t think it’s especially important to get the correct arrow to show whether an operation is synchronous or asynchronous. It’s much more important to document that an operation happens and in what order rather than get the little details correct.

To learn more about sequence diagrams and how to create them, here’s LucidChart’s tutorial and Visual Paradigm’s guide.

Benefits of diagrams

Whether you are interested in learning more about UML or never want to touch it again (both valid!), I hope that you’ll still try to find opportunities to visualize your code. Whatever combination of boxes and lines you draw is the right combination if it helps you understand your system and think deeper about what you’re building.

Before you start writing code, try sitting down to visually document what’s currently there and what you want it to look like when you’re done. This is especially helpful if the code you’re working with is a bit of a spaghetti mess. You can map out a variety of possible solutions and identify the pros and cons of each approach.

After you’ve finished coding a small chunk of work, try documenting the system, what decisions were made, and visually show the roadmap to get to your desired end state. If you decide to join the circus someday, the diagrams you made can continue to shepherd your team and the project forward 🎪

Drawing diagrams and developing your visual vocabulary can do wonders for your software development skills. It can grow your logical thinking skills and your ability to see multiple solutions to a single problem. And it can help you organize your thoughts to make the best decision with the information available. UML is complicated and it would take a lot of time to learn and memorize all the tiny details of when to use a closed arrow vs an open arrow. Be frugal with your time, use boxes and lines to get the most return on your investment.

Legacy application code review - Part 2: The details

Mercedes Bernard — Sat, 04 Jul 2020 18:37:41 +0000

This post is the second part in a series about what to look for when inheriting a legacy code base. This post will focus on looking at the details of the code itself.

Legacy code bases get a bad rap, but they can be even more fun than working from a clean slate. Not only do you have to make decisions that are extensible in the long-term, but you do that within the delicate balancing act of not breaking what is already there.

Since there are more dependencies and considerations to take into account when working with an existing application, I recommend doing a full code review and audit of the application before making any plans for future functionality. Having as much knowledge as possible will help you make informed decisions about the best path forward.

In this post, I outline a variety of things I recommend investigating during this code review, what we learn from those findings, and how to adjust your recommendations and estimates.

Automated static analysis

After gaining an understanding of the big picture and how all the pieces of an application fit together, we dig into the details of the application code. We begin by using a variety of tools for automated static analysis of the code base. Static analysis is done without running the code and focuses on the structure of the code. We look at an array of metrics to give us an understanding of how easy it will be to work with and how ready it is for extending. None of these metrics on their own show problems or tell the entire story, but they provide information for you to make decisions.

Analisis-Tools.dev maintains a wonderful list of static analysis tools organized by language for your reference.

Lines of code

The simplest metric to measure is the size of the code base. Large code bases are not inherently bad. But the larger the code base the longer it takes a new developer to find the relevant bit of code to change. Size is a helpful measure to consider when estimating so you can plan for the time it will take you to understand the code base.

Next, take a look at class and method length. Note the biggest classes and methods measured in lines of code. Similar to code base size, long classes and methods are not inherently bad (sometimes there is a good reason for a class to be larger than average), but long classes and methods take longer to understand and can be harder to refactor. Especially with methods, longer code typically hides more side effects that catch up to you when refactoring.

If you find that there are a lot of long classes and methods, you may want to adjust your estimates accordingly to give yourself some time at the start for a little refactoring. If you cannot refactor and feel that it's important, have a conversation with your stakeholders about the risk of unintended bugs introduced because of side effects hidden in the code you’re changing.

Duplication

You can also run checks to see how DRY code is. DRY stands for Don’t Repeat Yourself. Code that is DRY means that code is not duplicated in multiple places within the application. Not repeating code minimizes the number of places that need to be touched when you have to make a change. This limits the number of opportunities to introduce bugs into the code.

Hopefully, you find little duplication. If you find a lot and it’s in the relevant parts of the code you’ll be working in, increase your estimate a bit to give yourself time to consolidate the duplicated (or triplicated 😱) parts of the code.

Complexity and churn

Then you can measure complexity and churn. Complexity often refers to cyclomatic complexity and ABC (assignments, branches, conditionals) complexity.

Cyclomatic complexity is a fancy way to quantify how many linear branches through the control flow there are. It sounds complicated, but it usually mirrors the way people intuitively think about complexity in their code (computer scientists love intimidating vocabulary 🙄).

ABC complexity measures the number of assignments, branches, and conditionals in code. The branches part of ABC complexity lines up pretty closely with cyclomatic complexity.

And churn refers to how often a piece of code is updated.

On their own, none one of those measures tells you much. Taken together, they can tell you where the best candidates for refactoring are. Chunks of code that are high complexity and high churn should be refactored.

If a bit of code is highly complex, you don’t want to change it often so isolate it to its own file that can be left alone as much as possible.

If the code changes often, you want to make it very simple to understand so the changes aren’t hard to make. Both cases limit how likely it is to introduce accidental bugs into the code.

Test coverage

The last metric to analyze statically is test coverage. I don’t recommend looking for 100% test coverage, but 75-85% test coverage may show that the test suite will protect you from introducing unintended regressions. Test coverage is not enough to fully protect the code since the tests may not be robust. However, it’s a good quick measure for you to determine your confidence in changing the code base.

If you are working with a project with minimal to no test coverage, you may want to recommend spending time upfront adding test coverage to document the current state of the application. It’s helpful to educate your stakeholders about how robust test coverage doesn’t prevent bugs. It can prevent unintended behavior changes from making it to production and can document expected behavior for developers.

Automated security audit

While a full security audit is often out of the scope of this kind of code review, there are some tools we can use to identify known security vulnerabilities, such as Brakeman for Ruby on Rails or Snyk. Using a tool like this can help you plan for remediating any high priority vulnerabilities in the application and communicate immediate needs to your stakeholders.

Human analysis

Static analysis is great for quickly understanding the structure of a code base, but there are some cases where we can’t substitute the keen eye of a human engineer. You should examine the code to see how closely it follows established conventions and idioms of its framework.

Conventions

Highly idiomatic code is easier to onboard because you can quickly navigate the code base knowing where to look for files and functionality based on experience. Code that does not follow established conventions is slower to move around in since you are never sure where to look or where you’ll find the relevant bit of code.

Dead code

You should also try to get an understanding of how much code in an application is unused. There are some dynamic analysis tools that you could use for this. But most require deploying code to production so I rely on manual analysis if I haven’t started working on the project yet.

Unused code, or dead code, can affect the overall health of a code base. As you refactor and make changes to the application, you may invest time updating dead areas to keep a green test suite when you should remove dead code so you have more time to devote to the revenue-generating areas of the application.

Dependencies

Examine the major dependencies in an application to check that they are actively maintained. If you find dependencies that are not actively maintained, you may want to budget time for replacing those dependencies with modern, maintained alternatives. You’ll want to do this, especially if the upcoming feature work wants to build with this dependency. For example, creating fancier maps with a very old version of Leaflet or wanting to make graphs with an outdated charting library.

Updating dependencies can be tricky and should factor into your estimate. Keeping dependencies updated means that the project can continue to thrive and features continually added.

Documentation

The last bit to rely on human analysis for is reading the project documentation. If a project is not well documented, you may take that as a risk that there are potentially unknown features and functionality that you need to be prepared for. This won’t necessarily increase your estimate but is a helpful measure in understanding how difficult it will be to find answers and context if you find something odd in the application.

Dynamic analysis

Finally, try to run the application locally and use performance profiling tools to determine if there are any risks to your stakeholders’ load and scaling goals that should be addressed earlier rather than later. If you notice poor performance in an important area of the application, you may recommend addressing that early in the roadmap to meet the load demands once the project launches.

Benefits of robust code review

When you have a holistic understanding of an application, you’re able to provide informed recommendations of the technical areas your stakeholders should invest in and should deprecate. Technical debt is a fact of software life, but you can help them know where it’s worth paying down and where it’s a sunk cost.

Everything that you look at during a code review is in service of making sound recommendations driven by your stakeholders’ business goals while also providing more accurate estimates of the amount of effort it will take to deliver on those goals. It’s important not to view this review as a time to be judgmental but as a learning opportunity and a chance to prepare for a successful project.

Existing application code review checklist

Does it run?
Language/framework version support
Infrastructure version support - database, storage service, cache, message broker, etc.
Configured environments
CI/CD pipeline
Data model
Static analysis
1. Code base size
2. Class and method size
3. Cyclomatic complexity
4. Churn
5. Test coverage
Human analysis
1. Security audit
2. Code conventions and idioms
3. Dead code
4. Dependencies
5. Documentation
Dynamic analysis
1. Performance profiling

Legacy application code review - Part 1: The big picture

Mercedes Bernard — Sat, 04 Jul 2020 18:36:51 +0000

This post is the first part in a series about what to look for when inheriting a legacy code base. This post will focus on looking at the big picture of the application and how the system fits together.

In this post, I outline a variety of things I recommend investigating during this code review, what you learn from those findings, and how to adjust your recommendations and estimates.

Does it run?

Before you begin your code review, the very first thing to try is to run the application locally. If you’re unable to get the application running within an hour or two there may be a bigger issue hiding. And it’s not worth your valuable time to debug setup issues.

If you can’t get the code running following the documentation or standard industry practices, reach out to your stakeholders or previous developers. If the answer is that the code doesn’t run, then you should start having a larger conversation about stabilizing the development environment before even considering trying to estimate future functionality. It’s not prudent to estimate how much it will cost to build an addition on a house when the foundation is crumbling.

Language/framework audit

Once you have the code base running, check the language and framework version(s) of the application to determine its current support status. Running old versions of languages and frameworks can open the application up to unfixable bugs or unpatched security vulnerabilities. Using out-of-date versions may also limit your ability to deliver on big ideas if your stakeholders want modern features that aren’t possible with the old framework version they have.

Maintainers will deprecate older versions and no longer release updates after a certain date. Whether or not open source, these support timelines and policies are usually published publicly so you can plan your upgrades to stay ahead of deprecation and EOL (end of life).

For example, here’s a sample of open source and proprietary languages and frameworks just to give you an idea of what to expect.

Infrastructure audit

After you audit the backbone of the application, look at the supporting infrastructure to catalog the versions, support, and necessary dependencies. Pay special attention to the database but also look at other infrastructure driving the application such as storage services, caches, message brokers, etc. As before, you are auditing versions and if they are currently supported.

While it’s not required, I recommend drawing a diagram for yourself and your stakeholders showing how these pieces fit together. This is a brilliant place to add value as an engineer because often, no one understands the complete picture.

A diagram can help you technically by serving as a reference to the architecture of the system when you need to evaluate future services to integrate with. It can help your stakeholders gain an awareness of the complexity of their system, which helps form useful context when you propose a higher than expected estimate. Sometimes there’s even an added, immediate benefit of eliminating overhead by showing them they have unused services they are paying for that can be stopped!

While evaluating the infrastructure, make note of any interesting dependencies and considerations. For example, if you discover an Oracle database hooked up to the Rails app, do a little extra research to look into the ActiveRecord adapter for Oracle and document any limitations since Oracle isn’t a standard choice for a Rails app.

By paying attention to what infrastructure is there and how it’s configured, you can note any architectural considerations you may have when estimating and planning your project.

Environment audit

The next step in your code review is to learn about the various configured environments and their automated continuous integration and continue delivery (CI/CD) pipelines or lack of. Understanding the environments and how they fit together is key to planning your developer workflow and productivity and determining quality assurance (QA) and user acceptance testing (UAT) processes.

If there are no automated CI/CD pipelines configured, include time for setting those up in any estimates you provide. Automated CI/CD pipelines increase developer productivity by automating tedious parts of your work; decrease broken builds/deployments which limits regressions; increase code quality by enforcing that your code meets certain criteria before being deployed; and shortens time to market for your stakeholders by making it easier to deploy code early and often.

Data model and database design

It’s helpful to understand the project domain you’ll be working in by looking at the database and the relationships between the data models. Pay attention to how normalized the data is. Normalized data limits data redundancy. For most standard use cases, we want normalized data. If you find that the foreign key or association path to any single model in your database follows many routes, you have denormalized data.

There are tools out there that will generate an ERD (entity-relationship diagram) to make it easy to see these relationships. This is another place where you can start providing immediate value to your stakeholder if they do not already have their data relationships documented.

I like dbdiagram.io which lets you upload a variety of schema files and auto-generates a diagram for you. dbdiagram.io requires that your relationships are modeled in the database layer. If you find that most of your relationships are only modeled at the application layer (I’ve seen this happen in many Rails projects), you may need a different tool such as rails-erd, which will generate a diagram based on the ActiveRecord associations present in your code.

This is an example of denormalized relationships. Notice how many direct and indirect associations there are for the same relationships.

This is an example of mostly the same tables after they've been normalized. There are many fewer associations duplicating the same relationships.

Pay attention to what data constraints and validations are present. A strong combination of normalization and constraints protect the data from anomalies during insertion, update, and deletion that can introduce bugs into your application.

A database that is very denormalized or lacks constraints such as foreign keys or not nullable constraints informs you to plan time for remediating these concerns before adding new features. If you cannot make changes in the database, increase your estimate to allow yourself more time to write extra robust validation and error handling code. You’ll need to proactively prevent dirty data that could cause hard to find application bugs.

Conclusion

Understanding the various components of a system can help you understand the big picture and start to form system-level and architectural-level recommendations for your stakeholders. In the next post, we'll leave the big picture behind and dig into reviewing the application code itself.

Existing application code review checklist

Does it run?
Language/framework version support
Infrastructure version support - database, storage service, cache, message broker, etc.
Configured environments
CI/CD pipeline
Data model
Static analysis
1. Code base size
2. Class and method size
3. Cyclomatic complexity
4. Churn
5. Test coverage
Human analysis
1. Security audit
2. Code conventions and idioms
3. Dead code
4. Dependencies
5. Documentation
Dynamic analysis
1. Performance profiling

9 little details to remember on the day of your conference talk

Mercedes Bernard — Sun, 26 Jan 2020 17:14:46 +0000

Even for the most experienced speakers, being nervous is a normal part of the speaking experience. But the worst part about nerves is that they can make you focus so much on trying not to forget what you want to say, that you forget the tiny details. Remembering the little things can really elevate the talk experience for your attendees.

I’ve broken this list into 3 sections to help you organize on the day of your talk: what you should do immediately before you give your talk, what you should try to remember during your talk, and what you should do after your talk.

Immediately before your talk

1. Tweet out a link to your slides

If you’ve read my last post with tips about making slides, you’ll know that I think it’s a good idea to share your slides with your audience at the start of your talk so they can follow along. Tweeting out a link to your slides before your talk makes it easy for folks to find a link to click and quickly download your presentation.

2. Take off your name badge

Take off your name badge before you start speaking. If the conference has provided lapel mics, the name badge can rub up against it causing lots of distracting noises. It can also get in the way if you talk with your hands. And you probably prefer the outfit that you stressed about to take center stage both in person and on the video recording rather than the conference’s badge 😉

3. Extend your desktop so you can see your speaker notes

You’ll usually have somewhere between 10 and 30 minutes before your talk to set up your computer and slides depending on the conference schedule. Get all your dongles plugged in and make sure that your slides are visible on the correct screen(s). Don’t be afraid to take your time and make sure you extend your desktop so that you can see your speaker notes on your screen and the slides on the presentation screen. If you are using Google Slides (my preferred tool) or any tool that lets you customize what your speaker notes look like, resize them or move them around so that they are easily visible while you are speaking.

4. Plug in and turn on your clicker

Don’t forget to plug in and test your clicker during your tech check or in your setup time before your talk. I almost always forget to turn my clicker on and adding this reminder to my mental checklist has helped prevent some awkward fiddling before I start speaking.

5. Turn on your captions

Google Slides is an amazing presentation tool. Out of the box, Slides has a closed captioning feature so that you can provide live captions to your audience. This is an amazing accessibility feature and one that I love being able to provide even if the conference doesn’t have live captioning.

Most audiences aren’t used to seeing live captions during a conference talk, so I use my setup time to get them accustomed to seeing the words roll along the bottom of the screen. As soon as I have everything set up, I turn on the closed captioning and start chatting with people in the front row. The conversation usually turns to the captioning and I’m able to answer everyone’s questions. Doing this in the setup time before my talk prevents a lot of distractions when I start giving my talk and keeps the focus on my content.

During the talk

6. Always use the microphone

Microphones are there for the accessibility needs of your audience and audio track for your talk’s recording (if the conference is filming talks). Use them, no matter what. I promise you that you are not “loud enough without one” for the people who are relying on them in order to hear what you’re saying and learn from you. (On a related note, please do not ask the audience if they want you to use the microphone—you are asking people to identify their accessibility needs to a room of strangers.) And if the conference is paying for video recordings of your talk, using the microphone ensures that your recording will be usable.

7. Hold handheld mics like a popsicle, not an ice cream cone

This tip is courtesy of Liz Fong-Jones (@lizthegrey), and I love it so much. They’ve tweeted this tip a couple of times, and it’s extremely helpful for visualizing the correct way to hold a microphone. If the conference has provided you a handheld mic, you want to hold it parallel to the floor (like a popsicle!) and speak directly into it. If you hold it perpendicular like an ice cream cone, some of your sound will escape the mic and you won’t be fully amplified.

After your talk

8. When taking questions, repeat the question before answering

If you choose to take questions after your talk, be sure to repeat the question before answering it. You are the only person in the room with a microphone (usually) so you want to be sure that everyone in the audience heard the question and you want to make sure the question is captured on your talk recording’s audio track. Repeating the question also has the added benefit of you being able to paraphrase and check that you correctly understood the question before asking.

9. Remember that the next speaker needs time to set up too

When you finish, people will want to continue the conversation and talk to you. Yay! This means that what you said got them thinking, and they’re interested and excited about the topic. It’s normal to take a few individual questions at the podium, but remember that the next speaker needs to set up. Take a few questions while you’re cleaning up, but if someone wants to have a larger discussion, encourage them to find you in the hallway, at lunch, or at the conference after-hours events to pick up the conversation.

On the day of your conference talk, it’s normal to be nervous and focused on what you want to say. Thinking through little details ahead of time can help you feel more prepared and not forget them. Remembering things like these can go a long way in making your talk feel extra thoughtful and polished for your audience.

8 nitty gritty tips for creating valuable slides

Mercedes Bernard — Sat, 18 Jan 2020 17:03:35 +0000

Once you are accepted to speak at a conference, the anxiety of putting together the presentation sets in. Making interesting, well-organized slides with clear takeaways is hard. Like any skill, it takes a lot of practice to be good at it and even more practice to make them look professional and beautifully designed.

When making slides, it’s important to know that they are a presentation aid. Your speech is the presentation so not all of your content should be on your slides. You want what you’re saying to provide the majority of the value. After all, it was you that got invited to speak, not your slides.

Your slides are an important tool to help your audience follow along, emphasize your key takeaways, and a future artifact your attendees can refer to. Here are some of my tips for creating slides that your audience will get the most out of.

1. Content first!

This may be the most universal tip shared with new speakers about slides but that’s because it’s so important. When you’re making your slide deck, focus on creating and organizing your content before you worry about the design of your slides.
It can be challenging to stay with black text on a white background but try not to touch the design until you’ve nailed the content. Get all your ideas into the slide deck, reorder slides, refine the words on the screen, split up lists across slides, and find your transition points. When you feel confident in the content of your slides, then play with color and imagery to make your points pop!

If you have a habit of procrastinating, this tip is even more important! Designing slides sucks up a lot of time; you don’t want to run out before you organize and present all of your actionable takeaways in a memorable flow.

2. Use master slides

While you’re creating the content of your slides, be sure to take advantage of master slides. Master slides are templates with predefined slide layouts. They exist in every presentation tool: Google Slides (my preferred tool because of the live captioning feature!), Keynote, and Powerpoint. Even when you’re creating default slides with black text on a white background, make sure to choose master slide layouts closest to how you think you want to present the content. Is it a title slide? Should it have a header and body copy? Do you need 2 columns?

When you are ready to start designing your slides, master slides let you make font, size, color, and layout changes in one place. Those changes are then applied to all slides using that layout saving you from having to make layout changes on each slide individually. If you want to increase the width of a text box on all of your title slides, you can make that change on the master slide and it will automatically apply to all of your title slides.

Master slides come in handy if you have to make changes on the fly right before your talk. I had a friend who was giving a workshop and noticed that the presentation screen was a bit short. His footer with his contact info was cut off so attendees couldn’t see it. If he had been using master slides, he could have moved his footer up 20 pixels on the slide master to make it fit on the screen. Unfortunately, he wasn't using master slides and didn’t have time to change the 60+ slides in his deck individually.

3. Put your contact info on every slide

Include your contact info on your master slides. Many attendees will take pictures of a slide that resonates with them for future reference and to share on social media. If you have your website or Twitter handle on every slide, you make sure that your content is attributed to you. And it makes it easier for people to find you as content spreads across the Internet.

4. Check your slides for accessibility

We all want our slides to look visually interesting. Often, this means playing with color, size, and images. But don’t forget that if someone can’t read your slides they might as well not be there.

It’s trendy to do white text on dark backgrounds. But in some cases where the room has poor presentation lighting, your slides wash out and are hard to read. Dark text on a light background works better in unknown screen resolution and lighting scenarios. This is especially true if you are showing a list or other small text (such as code). When in doubt, choose a light background and dark text. You can also use accessibility checkers, such as WebAIM’s color contrast checker, to check the contrast of your slides (try to shoot for 4.5:1 or higher).

In addition to the color of text and background, be aware of the size of your text. You should always strive to make it as large as possible to ensure everyone in the room can see it no matter how far away they're sitting. This has the added benefit of forcing you to include fewer words per slide and increase the value of your voiceover.

Be mindful of your use of imagery and color to convey meaning. Try not to rely on imagery alone to convey meaning. If you must (sometimes graphs and charts are an impactful way to make your point), be ready to describe the image and include text descriptions on the slide or in your speaker notes. The same goes for color. Color alone is not sufficient for conveying meaning. If you have a list of items where some are written in green for good and red for bad, consider splitting the list and adding headings so that those in your audience who are colorblind receive the same information as everyone else.

Allison Ravenhall wrote a wonderful article for Smashing Magazine outlining even more tips for creating accessible and inclusive slide presentations that I highly recommend.

5. Type out your speaker notes ahead of time

I am not an advocate for memorizing every word of your talk ahead of time. But I do recommend that you type out your speaker notes in the presentation. (There is an area for speaker notes that attendees don’t see while you’re presenting.) Does it have to be full sentences of everything you’re going to say? No. But it should be more substantive than the little bit of text on your slides. Someone should be able to read your speaker notes and follow along with the meat of your talk, including the important takeaways.

Sharing your slides with speaker notes before you start (see below), is helpful for your audience. Providing speaker notes in the slides helps people with a variety of accessibility needs—low vision, attention deficit disorders, hearing loss, etc. If they can have your notes on their phone or laptop, they can follow along in a way that works best for them.

And providing your notes is a digital curb cut. It can help people who don’t usually have accessibility needs such as people who are taking notes and want to make sure they don’t get lost or tired parents who are struggling to stay awake.

Providing speaker notes can also help live captioners if the conference is staffing people to type out what you’re saying in real-time. They can refer to the notes to help them spell technical words. It also preps them with what you might say so it’s easier to keep up.

And finally, committing to typing your speaker notes beforehand helps you better prepare. Thinking through everything you want to say and writing it down can go a long way in helping you find sticky spots in your content that need to be smoothed out. For me, that’s usually the transitions and the conclusion.

6. Upload your slides somewhere shareable

Put your slides somewhere that other people will be able to view and download them. This allows attendees to download them while you're speaking so they can follow along as I mentioned above. And many attendees like to refer to slides later when they’re processing everything they’ve learned that day, when they want to blog about talks they’ve seen, or when they need to present to their team the valuable takeaways from the conference they attended.

Having publicly accessible slides can also help you land future speaking engagements. Event organizers may go look to evaluate your content and get a sense of how well your content is organized or how well it aligns with their event’s goals.

I host my slides on my personal website. Other speakers like Slideshare, Google Drive, Dropbox, and a variety of other document sharing platforms.

7. Include a link to your slides at the beginning of your presentation

During your intro, be sure to share a link to your slides so your audience can download them to take advantage of the wonderful speaker notes and content you’ve put together. Like I mentioned before, allowing people to have access to your slides on their phones or laptops while you’re speaking let’s them follow along in a way that best suits their needs. You are creating a more inclusive space for everyone with just a little bit of forethought and planning.

8. Don’t screenshot code

This last tip may not apply to everyone, but if you’re including code in your slides please don’t screenshot it. Put the text of the code in the slide with appropriate code formatting. Then your attendees will be able to copy/paste it rather than having to re-type it all if they use it later.

Getting the formatting correct in presentation software can be a challenge. My hacky workaround is to copy/paste my code into Google Docs and use the Code Blocks Add-on to format it according to the language and slide design. I tend to prefer a simple theme and use the googlecode theme most of the time.

Slides are an important tool for both you and your audience. A well organized and interesting slide presentation helps your audience follow along, emphasizes your key takeaways, and acts as a future artifact your attendees can refer to. So when you're making slides, try to keep the following in mind.

Content first!
Use master slides
Put your contact info in every slide
Check your slides for accessibility
Type out your speaker notes ahead of time
Upload your slides somewhere shareable
Include a link to your slides at the beginning of your presentation
Don’t screenshot code

So you want to start conference speaking? Submit that CFP!

Mercedes Bernard — Sat, 11 Jan 2020 21:29:54 +0000

This is the seventh and final post in a series on getting started as a conference speaker. This post focuses on submitting the CFP.

You have done so much prep work up to this point that this should be the easiest step. 🙌

Read the guidelines

When filling out the actual CFP, the golden rule is to read and follow all of the guidelines. Every conference and every CFP is different. Some want things formatted a certain way. Some want you to remove identifying information. Some want you to include past speaking experience and videos so they can take a look. Some have very interesting submission deadlines (I’m looking at you PyCon 👀 who has a deadline of Anywhere on Earth (AoE) instead of 11:59 PM EST like many conferences). To ensure that your proposal makes it past the first round of cuts, make sure that you meet all of their submission criteria.

Easy to understand title

The next tip for submitting a strong proposal is to pick a title that tells the audience exactly what your talk is about. Quirky and punny titles can be fun, but if an attendee wouldn’t be able to tell on the program what your talk is about, they probably won’t attend and the organizing committee wants to select talks that their attendees want to see.

Don't make the selection committee think too hard

Finally, remember that the organizing committee is reviewing hundreds (if not thousands) of talk submissions on a deadline. If they can’t figure out what your talk is about quickly, they don’t have time to put in the effort. Don’t make the organizing committee think too hard. Show that you are organized and prepared. Clearly outline what the talk is about and why it is important. There are often extra questions and response areas in addition to the abstract so that you can demonstrate that you know what you’re talking about and will give a stellar talk for your audience.

Make sure that you submit to as many different conferences as you can. Experienced speakers average a 20% or less acceptance rate on their talks. You have to play the numbers—the more you submit, the more conferences you will get accepted at.

Don’t get discouraged if your talk did not get selected. Most often, it was not because your submission was bad but because the programming committee had to make a decision and could only accept a small number of talks. That conference just happened to be in the 80% that you didn’t get picked for.

You are great and you have so much to share with your community! I can’t wait to see what you put together. And if you are looking for feedback, please reach out! I’d be happy to help if I can 🤗

Related resources

So you want to start conference speaking? Choose confs to apply to

Mercedes Bernard — Sat, 11 Jan 2020 21:27:12 +0000

This is the sixth post in a series on getting started as a conference speaker. This post focuses on choosing which open CFPs to apply to.

Now that you’ve found a list of conferences with open applications, how do you pick which ones to submit to?

I consider the following when choosing conferences

1. Who is the audience?

Is this a polyglot conference? Or is it targeted towards technologists using a specific tech stack or language? Is the audience mostly developers? Architects? Product managers? Data scientists? Testers? Other roles? Is the conference primarily in a spoken language you feel comfortable speaking?

Depending on the topic of the talk I’m proposing, I may want to find conferences targeting more people in leadership roles vs active hands-on-keyboard roles. If you are thinking about talking about software testing, you may want to focus on code-heavy and testing-heavy conferences.

2. What is the format?

Is this a one-day or multi-day conference? Is it a single-track or multi-track? How many attendees are expected? How long are the session spots?

Depending on your personal constraints, you may not be able to comfortably travel to multi-day conferences or you may want to commit to longer conferences so you can see more content on a single trip.

I prefer multi-track conferences to single-track conferences because then I know my audience chose to attend my session. Other speakers I know prefer single-tracks so they get their content in front of 100% of the attendees.

Consider how large your potential audience could be. If it’s a multi-track conference, is it 1000 people split over 3 tracks or 8? That could be the difference between 300 people or 100 people in your talk.

And finally, how long are the sessions? Are they an hour or 30 minutes? Do they give you the choice to submit a 15-minute lightning talk, a 45-minute session, or a 4-hour workshop? You want to make sure the content you’re ready to prepare fits the organizers' expectations.

3. What is the topic or theme?

Often, a conference may have a topic or theme for the year that they are focusing on. Does your content fit that theme? Can you easily make it fit?

4. Do the conference’s values match yours?

Consider all the time and energy you’re putting into speaking and making the conference a success. You want to make sure that you are giving that time to a conference that matches your values. Speaking at a conference implicitly and explicitly demonstrates that you support their work and their views.

Things to consider when trying to evaluate a conference’s values include

Code of conduct
Demonstrated inclusion and diversity practices
Past speakers they’ve invited
How the conference has handled constructive feedback from past attendees and speakers
Accessibility options provided by the conference
How they accommodate attendees with different needs
Ticket costs and conference finances
Past and current sponsors

5. What expenses are covered by the conference or your employer and what will need to come out of your pocket?

Finally, you have to make sure to consider your financial obligation of speaking at a conference. Will the conference cover your travel and accommodation costs? If not, does your employer cover them? If you are self-employed, does the ROI on your investment make sense for you? Do you have high confidence that this speaking opportunity will help you market and gain new business? If you want to do it for the pure enjoyment of sharing ideas with your community, can you reasonably afford the financial responsibility?

There is a lot to consider when deciding if a conference is a good fit for you and your content, but once you have a list of conferences that you want to apply to, apply to all of them! And submit multiple proposals to each to increase your odds of acceptance.

Related resources

So you want to start conference speaking? Find open CFPs

Mercedes Bernard — Sat, 11 Jan 2020 21:24:58 +0000

This is the fifth post in a series on getting started as a conference speaker. This post focuses on finding open CFPs.

Yay!!! At this point, you have all the pieces you need to start submitting your talk to conferences! Remember, you do not need to have the entire talk written before you apply to give it! But how do you find conferences who are accepting calls for proposal (CFPs)?

There are a lot of different sources to find open CFPs. Some conferences share their CFP on multiple sources and some don’t share on any, instead relying on their own social media and newsletters. Finding open CFPs is more of an art than a science.

Here is a list of resources I use and like, and sometimes there is overlap between them.

Papercall - Papercall is a platform where you can add your talks and submit them to different CFPs. You can save your talk and submit it to multiple different events which is a nice feature.
confs.tech - An open-source and crowd-sourced list of conferences around software development, including ones with open CFPs.
CFP Land - A website listing upcoming CFPs, it also has a newsletter you can sign up for to get a digest directly in your inbox.
SeeCFP - A Twitter account that tweets out upcoming and current open CFPs. It also has a newsletter you can sign up for to get a digest directly in your inbox.
Tech Daily CFP - A Twitter bot that retweets CFPs for tech conferences and code camps. Sometimes there are false positives but still a great resource.
Specific conference Twitter accounts - I follow the Twitter accounts of conferences I particularly like so I see updates about when they’re opening their CFPs directly

And <shameless plug>, I created a little React app that’s hosted on a free Heroku dyno to consolidate a bunch of these sources in one place. You can find it at cfp-organizer.mercedesbernard.com. It can be slow to boot up, but it’s a handy little tool if you want to check it out.

Finding open conference CFPs can be a challenge if you don't know where to look. As you start submitting to and attending more conferences, talk to other speakers to find out where they discover open CFPs as well.

Now that you've found a whole bunch (and I mean a whole bunch) of open CFPs, the key to not stressing out is to decide which to fill out and which to skip.

So you want to start conference speaking? Choose your headshot

Mercedes Bernard — Sat, 11 Jan 2020 21:23:28 +0000

This is the fourth post in a series on getting started as a conference speaker. This post focuses on how to choose your headshot.

In addition to a speaker bio, most conferences will ask for a headshot to use on their website. The key to a good headshot is a high resolution, square, color photo with a plain background.

Most modern phone cameras will take a beautiful high-resolution photo so this isn’t as challenging as it used to be. A high-res photo will hold up better as the conference resizes it to fit on all of the mediums they need it (website, printed schedule, schedule displays outside of the session rooms, social media, etc). You're less likely to end up with a grainy image of you shared with all the conference attendees.

Using a color photo is also a considerate choice for the conference organizers. If the conference’s website design is in black and white, they can easily grayscale your color photo but if you give them a black and white photo and they have rich color photography, your headshot will look out of place from the rest of the photos.

And, please please please pick something with a relatively plain, quiet background. I’ve heard horror stories of volunteers and interns having to try to separate the speaker from the image background for the website design and the speaker submitted a headshot of them standing in front of a tree or a bush. Those poor volunteers spent hours on a single headshot. Just like using a high-res, color photo, a plain background gives the conference more latitude in making your headshot match the design of the rest of the conference assets.

The last bit of advice I’ll offer is to use a photo that looks like you. Many attendees will refer to photos before they come up to talk to you to make sure that they’re talking to the right person. Using a photo of your dog or your favorite anime character is cute, but your speaker headshot is not the right use case for that image. Save it for your Slack avatar or Twitter image.

Have you noticed that we're already on step 4 and we still haven't written your talk?? This is intentional. My rule of thumb is 1 hour of preparation (writing, creating slides, practicing, editing, etc) for each minute of the talk, i.e. for a 40-minute talk I plan for 40 hours of preparation. Putting all of that time into a talk before you know if its been accepted or not is a huge commitment. Your talk might be amazing but just not the right fit for the audiences you pitched. It’s better to save your time and mental energy for preparing your talk after someone has asked you to give it.

Related resources

Lady Conference Speaker Headshot by Heidi Waterhouse

So you want to start conference speaking? Write your speaker bio

Mercedes Bernard — Sat, 11 Jan 2020 21:21:15 +0000

This is the third post in a series on getting started as a conference speaker. This post focuses on how to write your speaker bio.

Now that you have a strong, informative abstract, you are almost ready to start applying to speak at conferences and submitting your CFP. But almost every conference is going to ask you for a speaker bio. Rather than try to come up with that on the spot in the last 30 minutes before the application closes (because we all procrastinate at some point right? 😉), let’s take some time and write that out beforehand.

A good speaker bio is also short, only 3-4 sentences. Think of it as your own personal abstract. Your bio should answer

Who are you?
What qualifies you to give this talk? What perspective do you have?
What is something fun for them to remember you by? What is something they can chat with you about at mealtimes?

We all feel pressure when writing our bios to tell people why we’re amazing and list our accomplishments. But I don’t think that’s the best use of this space. The speaker bio helps your audience understand your perspective and decide if they think you’ll have something unique and interesting to say on the topic. A list of awards isn’t as memorable as someone sharing why they are uniquely qualified to talk to a room of strangers about their topic.

Including something fun and interesting about yourself at the end often sets you apart from other speakers. It gives shy or nervous attendees an easy opener if they see you at the conference. As a speaker, many people will want to chat with you and hear more about what you have to say. An interesting line about spinning your own yarn (from one of my bio’s) or watching Star Trek (from a friend’s) can be the perfect little nugget to bond over and start a larger conversation.

Writing about yourself feels weird, especially in the third person. Find a friend to read your new bio and give you feedback. Friends are usually better at telling us why we're awesome than we are anyway 😉

And don't be afraid to sell yourself as the amazing speaker you are, that's the point of this exercise. You have a unique perspective, you're going to put in the work to make a valuable talk, and gosh-darn-it people will learn a lot from you!

Related resources

So you want to start conference speaking? Craft an abstract

Mercedes Bernard — Sat, 11 Jan 2020 21:18:10 +0000

This is the second post in a series on getting started as a conference speaker. This post focuses on how to create an abstract for your talk.

After you have an idea for the conference talk you want to give, the next step is to create an abstract that succinctly explains the talk and grabs the audience's (and conference organizers’) attention.

A good abstract will answer the following questions

Why is the talk important? What is the value proposition?

What will the talk teach? What is the outcome or takeaway for the audience?

How will it achieve that outcome?

And any additional information to help the audience decide if this talk is for them — who is it relevant to? what types of teams or organizations will find this helpful? etc.

A good abstract will answer all of these questions in 3-5 sentences. I’ve seen longer abstracts and depending on the talk and the conference, that’s ok. But 3-5 sentences is a good rule of thumb to follow for creating a strong abstract that will work well for a variety of conferences and audiences.

It can be challenging to answer those questions concisely and still sound interesting and inviting. I’ve found that the easiest way to do this is to not start by writing the abstract. Instead, build up to it with a bit of prewriting.

My process is heavily informed by Write, Speak, Code’s curriculum and I’ve found it to be immensely helpful in breaking the writer’s block that comes from trying to type up an abstract on a blank page.

Here is the template I use to work up to writing an abstract.

1. Brainstorm

I start with figuring out what format of a talk I want to give (my sweet spot is 30-40 minutes but some people prefer longer, some shorter). Then I brainstorm/word vomit/mind map all the ideas I have that I want to address in the talk in some way. This allows me to see if I have enough content to fill my desired timeslot.

2. Audience

From there I think about who my ideal audience is. No talk will appeal to everyone and you often want a bit narrower audience so you can tailor your content to their specific needs. When you target too broad of an audience, you run the risk of making a bland talk that appeals to no one instead of everyone.

3. Outcome

After I know who I want to talk to, I think about what I want them to take away from my talk. What do I want them to learn? What do I want them to feel? What do I want them to think differently about? What process or idea do I want them to try on their teams or projects after they see my talk?

4. Outline

Then I try to put together an outline of my talk. This is a super simple outline at this point, just the level 1 headings of the topics I hope to cover. This helps me get a sense of the flow of the talk that I can use to inform my abstract.

5. Description

The last step before I write my abstract is to just long-form describe what my talk is. I’ll use the information from the previous sections to write a paragraph or two describing what my talk is about, who it’s for, and why it’s important.

6. Abstract 🎉

Finally, I use all of this prewriting to write my 3-5 sentence abstract that answers those 4 questions from above. I edit my sentences to make sure I have a little punchier language than my long-form paragraphs but nothing that appears in my abstract is net-new from what I just spent an hour or two thinking about during the pre-writing.

Writing an abstract is HARD. You want to clearly explain why your talk is going to be worth the audience's time while also being entertaining and sounding smart. But don't overthink it! A little prewriting and following a process that works for you can go a long way in making this step easier. After you have an abstract you're proud of, you have to write a bio to tell the organizers and audience a little about yourself.

DEV Community: Mercedes Bernard

Jest mocking strategies

Table of contents

ES6 Exports

Default export of a vanilla function

Named export of a vanilla function

Default export of an object

Named export of an object

Default export of a function that returns an object

Named export of a function that returns an object

Mock behavior

Browser functionality

For the whole test suite

In a single file

Node modules

For the whole test suite

In a single file

A single function of a node module

For the whole test suite

In a single file

In a single test

Common mocking errors

The module factory of jest.mock() is not allowed to reference any out-of-scope variables

Cannot spy the default property because it is not a function

Cannot set property of #<Object> which has only a getter

Warning: An update inside a test was not wrapped in act

Boxes and lines: a frugal person's UML

What is UML?

Why UML?

Structure diagram

Behavior diagram

Interaction diagram

Benefits of diagrams

Legacy application code review - Part 2: The details

Automated static analysis

Lines of code

Duplication

Complexity and churn

Test coverage

Automated security audit

Human analysis

Conventions

Dead code

Dependencies

Documentation

Dynamic analysis

Benefits of robust code review

Existing application code review checklist

Legacy application code review - Part 1: The big picture

Does it run?

Language/framework audit

Infrastructure audit

Environment audit

Data model and database design

Conclusion

Existing application code review checklist

9 little details to remember on the day of your conference talk

Immediately before your talk

1. Tweet out a link to your slides

2. Take off your name badge

3. Extend your desktop so you can see your speaker notes

4. Plug in and turn on your clicker

5. Turn on your captions

During the talk

6. Always use the microphone

7. Hold handheld mics like a popsicle, not an ice cream cone

After your talk

8. When taking questions, repeat the question before answering

9. Remember that the next speaker needs time to set up too

8 nitty gritty tips for creating valuable slides

1. Content first!

2. Use master slides

3. Put your contact info on every slide

4. Check your slides for accessibility

5. Type out your speaker notes ahead of time

6. Upload your slides somewhere shareable

7. Include a link to your slides at the beginning of your presentation

8. Don’t screenshot code

So you want to start conference speaking? Submit that CFP!

Read the guidelines

`The module factory of jest.mock() is not allowed to reference any out-of-scope variables`

`Cannot spy the default property because it is not a function`

`Cannot set property of #<Object> which has only a getter`

`Warning: An update inside a test was not wrapped in act`