Make Elixir Tests Faster

Everybody wants faster tests, and nobody wants to spend more time than necessary writing them. In this article, I will show a few ways to make Elixir tests faster.

Run Tests In Parallel

The most obvious way to make tests faster is to run them in parallel. ExUnit of course makes this easy with async: true:

defmodule MyTest do
  use ExUnit.Case, async: true

  # ...

But you have to remember to add async: true to every test, and remembering is hard, especially when there are multiple people working on the codebase. Luckily, Credo has a check called PassAsyncInTestCases . Just add the following to your .credo.exs in the Refactoring Opportunities section:

{Credo.Check.Refactor.PassAsyncInTestCases, []},

Credo will now fail if you don’t explicity add an async value (either true or false).

If you aren’t already using Credo, I’d recommend adding it. You can disable the checks you don’t care about or that would be too time-consuming to fix right now. I’d recommend running it in CI at the very least, but you might also want to run it before checking code in (via a commit hook or perhaps in your shipit script), or even directly in your editor.

Run Fewer Tests

mix test has a --stale option that only runs tests that reference files which have changed since the last time you ran tests with this option. If you get in the habit of running mix test --stale, you will end up saving time by running fewer tests. It’s probably a good idea to run the full suite before pushing code.

When running mix test --stale, you might be surprised at the number of tests that run. If your project has a big web of module dependencies, then changing one module might cause a lot of other modules to change, causing mix test --stale to run a lot of tests.

This is where the Boundary library comes in handy. It will help you enforce boundaries between different sections of your codebase, which will reduce the number of modules that get compiled when you make a change, which will cause fewer tests to run via mix test --stale, which will result in a faster test suite.

Installing Boundary is not hard. Fixing boundary violations can take time though. I’d recommend installing it as soon as possible, and then allowing existing boundary violations so that you can at least get alerted to new boundary violations. Over time, you can clean up the existing violations to further decrease compilation times and increase stale-test speed.

Sleep Less

When testing some asynchronous code, your test sometimes has to wait for the async action to complete before it can successfully assert on the state. The easy way to do this is just drop in :timer.sleep(1_000) and hope that the async action has finished. Unfortunately, this has the dual downsides of making the test suite slower and more flaky.

A better way is to retry your assertion repeatedly until it passes. The Moar library (of which I am an author) has a Retry module with retry_for and rescue_for! functions:

# repeatedly retry up to 5 seconds for the element with ID "status" to be "finished"
Moar.Retry.rescue_for!(5000, fn ->
  assert view |> element("#status") |> render() == "finished"
end)

# repeatedly retry up to 5 seconds for the element with ID "status" to be "finished",
# and then make a different assertion
Moar.Retry.retry_for(5000, fn ->
  view |> element("#status") |> render() == "finished"
end)

assert view |> element("#total") |> render() == "8,675,309"

There is a downside to all that retrying and waiting: you are doing unnecessary work which may slow down the test suite (but probably not as much as sleeping for a long time does). Another approach is to send a message to your test when the thing you are waiting for has finished. Look for a future article about how to do that.

Internships

Perhaps the most impactful part of my college career was being placed at a two-semester, full-time, paid internship (extending my time at school from 4 years to 5 years). I learned a lot, got good work experience, and made new friends. I even stayed on as an employee for a while after graduating from college, which made getting my next job eaiser.

The internship program at my university was optional, but many educational programs have made internships a required part of their training. The most well-known example is medical residency, where new medical degree recipients work under the supervision of senior clinicians to work towards obtaining a license to practice medicine.

My internship placement was straightforward: I looked through a binder of possible internships, applied to one, and luckily they accepted me.

For programs that require internships as part of their training, a better system is obviously needed. The system commonly used for medical residencies and many other internship types allows the prospective interns and the internship sites to rank each other after going through an interview period. Once all the interns and sites have finished ranking each other, an algorithm is used to instantly place interns at sites, weighing the prospective interns’ preferences higher than the sites’ preferences.

Ranked Placement

I’m excited to announce that my Reflective Software co-founder Eric Saxby and I built and launched such a system in late 2024. We call it Ranked Placement. Since its launch, it has matched hundreds of students in internships for our pilot customer, the Bay Area Practicum Information Collaborative.

Ranked Placement is an easy-to-use application and placement system that can be used for various types of ranked-choice internship and practica matching. We are now ready to onboard additional customers. Please contact us at contact@rankedplacement.com to learn more.

Why Boundary?

Boundary by Saša Jurić:

Boundary is a library which helps managing and restraining cross-module dependencies in Elixir projects. A few examples of the things you can do with boundary include:

• Prevent invocations from the context layer to the web layer
• Prevent invocations from the web layer to internal context modules
• Prevent usage of Phoenix and Plug in the context layer
• Limit usage of Ecto in the web layer to only Ecto.Changeset
• Allow :mix modules to be used only at compile time

Restricting certain layers of your application from calling each other can make your application easier to change, but it can also help reduce incremental compile time. Have you ever changed a couple lines in a LiveView and had to wait for 43 files to compile? Boundary can save you from that pain.

When Boundary?

You can add Boundary to your application at any time, but it is far easier to add it from the very beginning. Just do it. If it doesn’t work out for you, it’s very easy to remove. Installation instructions.

A newly-generated Phoenix project has a standard module layout. My Reflective Software co-founder and I have experimented with different module layouts over the years and this is what our projects currently look like:

Core                      # instead of something like "MyApp"
  Core.People             # a context module
    Core.People.Profile   # contains changeset function(s) and an embedded Query module
    ...
Etc                       # its sub-modules could be external libraries but are too small for that
  Etc.S3Uploader          # has functions for uploading to S3
  ...
Extra                     # its sub-modules "extend" library functions
  Extra.URI               # has extra URI-related functions like `Extra.URI.path/1`
  ...
Schema                    # contains schemas and structs
  Schema.Profile          # just the database schema for Profiles; no functions
  ...
Web                       # instead of something like "MyAppWeb"
  Web.Components          # Phoenix components
    Web.Components.Nav    # a component
    ...
  Web.Controllers         # Phoenix controllers
    Web.Controllers.Home  # a controller
    ...
  Web.Live                # Phoenix LiveViews
    Web.Live.Profile      # a LiveView
    ...
  Web.Plugs               # Plugs
  endpoint.ex
  router.ex
  ...

Along with this layout, we use the Boundary library to define and enforce boundary separation. (Tip: it’s a lot easier to enforce boundaries if you set them up at the beginning of a project.) A project’s boundaries might look like this:

# Core
deps: [Etc, Extra, Schema]

# Etc
deps: []

# Extra
deps: []

# Schema
deps: []

# Web
deps: [Core, Etc, Extra, Schema]

One obvious difference between this layout and the generated code is that instead of MyApp and MyAppWeb, we use Core and Web. It’s just as descriptive, a lot shorter, and easier to copy from other projects.

Another difference is that we split “models” into changeset modules and schema modules. A schema module just defines a schema struct, and is accessible from modules such as Web. A changeset module defines changesets and has an internal Query module containing composable query parts; it is not accessible from modules like Web.

defmodule Schema.Profile do
  use Schema

  @type t() :: %__MODULE__{}

  schema "profiles" do
    field :name, :string
    field :slug, :string
    field :totp_secret, :binary, read_after_writes: true

    belongs_to :org, Schema.Org

    timestamps()
  end
end

defmodule Core.People.Profile do
  import Ecto.Changeset

  @type t() :: Schema.Profile.t()

  @required_attrs ~w[name]a
  @optional_attrs ~w[org_id]a

  def changeset(data \\ %Schema.Profile{}, attrs) do
    data
    |> cast(Map.new(attrs), @required_attrs ++ @optional_attrs)
    |> put_slug()
    |> validate_required(@required_attrs)
    |> unique_constraint(:slug)
  end

  defp put_slug(changeset) do
    case fetch_field!(changeset, :name) do
      nil -> changeset
      name -> changeset |> put_change(:slug, Extra.String.to_slug(name, random: 4))
    end
  end

  defmodule Query do
    import Ecto.Query
    alias Core.People
    alias Schema.Profile

    def base,
      do: from(_ in Profile, as: :profiles) |> default_order()

    def default_order(query \\ base()),
      do: query |> order_by([profiles: profiles], asc: profiles.name, asc: profiles.seq)

    def join_emails(query \\ base()),
      do: query |> join(:left, [profiles: profiles], email in assoc(profiles, :emails), as: :emails)

    def where_email_address(query \\ base(), email_address),
      do: query |> join_emails() |> People.Email.Query.where_address(email_address)
  end
end

defmodule Schema.Message do
  @type t() :: %__MODULE__{}
  defstruct ~w[body subject]a
end

Look for a future blog post about changesets and composable queries.

A relatively new feature of Phoenix is verified routes, which lets you create routes with the ~p sigil that result in compiler warnings when the route is invalid. For example, ~p"/users/new" will fail if there is no such path defined.

You can sprinkle your code with ~p sigils, but I’ve found that there are advantages to having a module that contains functions for each path in your project, like this:

defmodule Web.Paths do
  use Web, :verified_routes

  @customer_id "58-gkjScjj8"

  def home, do: ~p"/"
  def invitation(%Schema.User{type: admin} = user), do: ~p"/admin/invitation/#{user.id}"
  def invitation(user), do: ~p"/invitation/#{user.id}"
  def login, do: ~p"/auth/login"
  def logo, do: static("images/logo.png")
  def remote_auth, do: "https://auth29-g.example.net/customer/#{@customer_id}/auth"
  def styleguide(module, function), do: ~p"/styleguide/#{module}/#{function}"
end

Note that in this example, the module is Web.Paths, not MyAppWeb.Paths. See Phoenix Project Layout for more info.

More things to note:

• As a plain module with functions, your editor can autocomplete your routes.
• The functions usually fit on a single line, so you can see a lot more routes at a time.
• A different invitation path is returned by pattern matching on the user type which reduces the need for duplicated code that chooses the correct route.
• The logo isn’t a ~p sigil but using the generated route works the same as other routes.
• Function parameters are listed so it’s easy to tell what’s required.
• You can name your functions something that’s more meaningful than the path or URL.

Nova is a code editor written by Panic, the makers of your favorite FTP app. I’ve written several extensions for Nova. A few of them have also been ported to other editors by me or by other people.

Copy Path

This extension copies the absolute or relative path of the current file, optionally including the line number and column number.

Read more in the readme, or open it directly in Nova itself.

Document Sections

Sometimes, despite your best efforts, a document gets very large and hard to navigate, and for whatever reason, the language server can't help you navigate. This extension provides commands to let you go to a specific section of a document, or to go to the previous or next section. A section is defined by a line of text that starts with a section indicator, optionally followed by some text terminated by a newline.

Read more in the readme, or open it directly in Nova itself.

Elixir Manual Formatter

Sometimes the ElixirLS extension fails to automatically format one or all files. This extension provides a command to format the current file, and a command to format all files. It intentionally doesn’t try to format on save because the ElixirLS extension normally does that correctly.

Read more in the readme, or open it directly in Nova itself.

Go To Tab

This extension shows a list of open editors and lets you choose one to go to.

Read more in the readme, or open it directly in Nova itself.

Open File at Path

This extension opens a palette into which you can type a file path and optionally line number and column number. The palette will default to the first line of text from the clipboard. This is especially useful when you have a file path in some stack trace or test failure but you can't click on it because it’s in a Report, or Nova doesn’t recognize it because it has a line number and maybe a column number appended.

Read more in the readme, or open it directly in Nova itself.

Open Recent

Open Recent shows a list of recently-used editors and lets you choose one to open.

Read more in the readme, or open it directly in Nova itself.

Open Related File

This extension opens a file related to the current file. It’s common for code editors to have a built-in or extension-provided feature to switch between a code file and its test, using some heuristics that work most of the time. Some editors and extensions will also try to jump to other kinds of related files, such as CSS files. In my experience, these tools find the related files often enough to sound promising, but are frustrating in practice because they don't work 100% of the time, or don’t work on entire types of files.

This extension allows authors to specify each related file using a simple syntax. The upside is that the extension works perfectly all the time. The downside is that the author has to list each related file and has to update them when files move. To specify a related file, add an annotation somewhere in the file (perhaps in a comment).

The annotation must start with “@related” and contain one or more Markdown-style links in the form “[name](file-path)”, where “name” is any string and “file-path” is a path to the file, relative to the project root.

Read more in the readme, or open it directly in Nova itself.

Smart Sort Lines

This extension sorts lines of code with a little bit of intelligence when sorting a multi-line, comma-separated list. If all but the last line of text end with a comma, then after sorting, all but the last line of text will still end with a comma.

Read more in the readme, or open it directly in Nova itself.

Trail

This extension lets you create a trail of editor positions as you navigate code so that you can easily get back to where you came from. As you navigate your code, push waypoints onto Trail’s stack with the “Push Waypoint” command. Then when you want to get back to where you came from, pop the last waypoint off of Trail’s stack with the “Pop Waypoint” command which will move the text cursor to the file, line, and column that you previously pushed. If you want to pop multiple waypoints at once, use “Pop To Waypoint” which will show you the entire stack to of waypoints to choose from.

Read more in the readme, or open it directly in Nova itself.

My colleague Eric Saxby and I created two Elixir libraries for finding and extracting information from HTML and XML. One is called HtmlQuery and the other is called XmlQuery.

Quick overview

Before diving into the details, here is a quick overview.

<h1>Please update your profile</h1>

<form id="profile" test-role="profile">
  <label>Name <input name="name" type="text" value="Fido"> </label>
  <label>Age <input name="age" type="text" value="10"> </label>
  <label>Bio <textarea name="bio">Fido likes long walks and playing fetch.</textarea> </label>
</form>

<profile id="123">
  <name>Fido</name>
  <age>10</age>
  <bio>Fido likes long walks and playing fetch.</bio>
</profile>

HtmlQuery.find(
  html_contents,
  "textarea[name=bio]"
)
|> HtmlQuery.text()

# returns "Fido likes long walks and playing fetch."

XmlQuery.find(
  xml_contents,
  "//bio"
)
|> XmlQuery.text()

# returns "Fido likes long walks and playing fetch."

Motivation

In the 6 years or so that we have both been writing Elixir software, we have needed to search and extract a lot of HTML and XML. The HTML searching and extracting has been mostly in unit tests of web apps. The XML searching and extracting has mostly been in healthcare data processing apps.

We started writing various helpers in each project we worked on and eventually extracted HtmlQuery, and more recently, XmlQuery. The API has changed over time, starting off relatively simple, then getting more complicated, and then eventually back to simple but easily composable.

The API

The API has 3 main query functions: all/2, find/2, and find!/2. They each take a string of HTML or XML (depending on the library) and a CSS selector (for HtmlQuery) or an XPath (for XmlQuery). all/2 returns every element that matches the selector, find/2 returns the first element that matches the selector (or nil if none is found), and find!/2 returns the single element that matches the selector, raising if no elements were found or if more than one element was found.

Once an element is found, text/1 returns its text, and attr/2 returns the value of the given attribute. When finding multiple elements with all/2, we discovered that it’s simpler to pipe the results into another function, rather than having various options built into all/2. So to get the text or value of each button in the following HTML:

<fieldset>
  <input type="radio" name="animal" value="1">Ant</input>
  <input type="radio" name="animal" value="2">Bat</input>
  <input type="radio" name="animal" value="3">Cat</input>
</fieldset>

you would use the following code:

# text
html
|> HtmlQuery.all("input[type=radio]")
|> Enum.map(&HtmlQuery.text/1)

# value
html
|> HtmlQuery.all("input[type=radio]")
|> Enum.map(&HtmlQuery.attr(&1, :value))

That’s the main API. Easy to remember, yet very powerful. For a more detailed description, documentation about some extra functions, and details on a shortcut for writing CSS selectors, check out the documentation for HtmlQuery and the documentation for XmlQuery.

Hand-rolling an RSS feed with Elixir and Phoenix is pretty straightforward. You just need a list of feed items, a controller, a template, and a view. In this article, I’ll assume the list of items is a list of blog articles.

Articles

A simple way to store your articles is in a list somewhere. A more complicated way is to store it in a database. I’ll assume we’re storing it in a list.

defmodule Core.Articles do
  @articles [
    %{title: "Apples", description: "Red or green fruit", published_at: ~U[2024-02-25 00:00:00Z], slug: "apples"},
    %{title: "Bananas", description: "Yellow fruit", published_at: ~U[2024-02-26 00:00:00Z], slug: "bananas"},
    %{title: "Cherries", description: "Red fruit", published_at: ~U[2024-02-27 00:00:00Z], slug: "cherries"}
  ]

  def articles, do: @articles
end

Controller

All the controller needs to do is render an XML template:

defmodule Web.RssController do
  use Web, :controller

  def index(conn, _params) do
    render(conn, "index.xml", articles: Core.Articles.all(), host: conn.host, port: conn.port)
  end
end

Template

The template needs to include some header information, and then iterate over the articles:

<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Favorite Fruit</title>
    <description>A list of fruit</description>
    <link>https://example.com/</link>
    <lastBuildDate><%= pub_date(@articles) %></lastBuildDate>
    <pubDate><%= pub_date(@articles) %></pubDate>
    <ttl>1800</ttl>
    <atom:link href="https://example.com/rss" rel="self" type="application/rss+xml"/>

    <%= for article <- @articles do %>
      <item>
        <title><%= article.title %></title>
        <description><![CDATA[ <%= article.description %> ]]></description>
        <link><%= "https://example.com/#{article.slug}" %></link>
        <guid isPermaLink="false"><%= article.slug %></guid>
        <pubDate><%= pub_date(article) %></pubDate>
      </item>
    <% end %>
  </channel>
</rss>

View

The view needs to implement a couple helper functions for the template.

defmodule Web.RssView do
  use Web, :view

  def pub_date(nil), do: ""
  def pub_date(articles) when is_list(articles), do: List.first(articles) |> pub_date()
  def pub_date(article), do: format_rfc822(article.published_at)

  def format_rfc822(date_time), do: Calendar.strftime(date_time, "%a, %d %b %Y %H:%M:%S %Z")
end

Wrap up

Add a route to your router:

get "/rss", Web.RssController, :index

and add a link to the “head” section of your “app.html.heex” template:

<link rel="alternate" type="application/rss+xml" title="RSS feed for example.com" href="/rss" >

and you’re all done. Easy to do without having to add an external dependency.

Sharing project configuration and practices with a dev team can be tricky. Readme files are nice but become outdated quickly. Setup scripts, Docker, Chef, etc., are inflexible and add an extra layer of complexity.

In between those two extremes is doctor, a script that checks your dev environment and suggests remedies to the problems it finds. If you don’t like the suggested remedy, you can fix the problem some other way.

Setting up a project on a new computer is easy: clone the project from source control and then run doctor; it will tell you what your computer is missing (languages, databases, environment variables, etc.) and suggest a way to fix each problem.

It’s also easy to add new checks and commit them along with your code changes, so you can make code changes that require development environment changes without worrying about breaking other developers’ environments: doctor just runs the check when the developers update from source control, and then suggests a remedy if necessary.

Most importantly, doctor is an alternative to people hesitating to make changes to code because they are worried about breaking other people's development environments.

Here’s a typical doctor session:

% bin/dev/doctor

[checking] homebrew: bundled?... OK
[checking] direnv: installed... OK
[checking] direnv: .envrc file exists... OK
[checking] asdf: installed... OK
[checking] asdf: erlang plugin installed... OK
[checking] asdf: elixir plugin installed... OK
[checking] asdf: nodejs plugin exists?... OK
[checking] asdf: tools are installed... OK
[checking] deps: elixir deps installed? (needed for yarn to compile)... OK
[checking] yarn: up to date... OK
[checking] phantomjs: installed... OK
[checking] postgres: launchctl script is linked... OK
[checking] postgres: running... OK
[checking] postgres: role exists... FAILED

Possible remedy: createuser -s postgres -U $USER
(it's in the clipboard)

In my projects, I typically check:

• All the different programming languages are installed and at the right version.
• All the different databases are installed, configured, and running.
• All the necessary system tools are installed.
• All the necessary environment variables are set.

I used to write doctor scripts in Bash because it’s ubiquitous and typically doesn’t require any configuration, but recently my business partner and I have built an implementation of doctor plus other workflow scripts in Elixir (medic-ex), and we are now re-writing it in Rust (medic-rs).

For the past decade or so, I’ve added a group of scripts to every project I’ve worked on. These scripts started out relatively simple and automate some very common tasks. Scroll to the end for some updates.

Why Automate?

Automation encodes the team’s decisions in committed code, reducing questions (such as “do we like to do git pull --rebase or just git pull?”) and reducing problems caused when people forget to perform a step (such as running tests before pushing code).

How To Automate

Because Bash is ubiquitous, I typically write the scripts in Bash. Sometimes I write them in a more powerful language if they are complex. I personally put them in the bin/dev directory (I’ll often have a bin/prod directory for performing production actions, like bin/prod/ or bin/prod/logs).

Update

The update script is run when the developer wants to get the latest code onto their computer. It typically:

• pulls code from the git remote
• updates dependencies
• runs migrations
• runs doctor

#!/usr/bin/env bash

set -e

CYAN='\033[0;36m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

step() {
  description=$1
  command=$2

  echo -e "\n${CYAN}${description}: ${YELLOW}${command}${NC}"
  eval "${command}"
}

step "Pulling" "git pull --rebase"
step "Updating deps" "MIX_QUIET=true mix deps.get"
step "Migrating" "mix ecto.migrate ecto.dump"

bin/dev/doctor

Test

The test script runs all the tests. A script is useful for this so that everyone runs tests the same way, and so changes to the way the team runs tests are automatically shared by everyone.

#!/usr/bin/env bash

set -e

CYAN='\033[0;36m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

step() {
  description=$1
  command=$2

  echo -e "\n${CYAN}${description}: ${YELLOW}${command}${NC}"
  eval "${command}"
}

step "Running JS tests" "(cd assets && yarn run mocha)"
step "Running Elixir tests" "mix test --color"

Shipit

The shipit script is run when the developer wants to push code to the git remote. It typically:

• runs the update script
• re-compiles, ideally treating warnings as errors
• runs tests
• pushes to the git remote

#!/usr/bin/env bash

set -e

CYAN='\033[0;36m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

step() {
  description=$1
  command=$2

  echo -e "\n${CYAN}${description}: ${YELLOW}${command}${NC}"
  eval "${command}"
}

bin/dev/update
step "Recompiling" "mix compile --force --warnings-as-errors || (mix clean && false)"
bin/dev/test
step "Pushing to git" "git push"

Start

The start script starts the server or app. It’s usually not a complicated script but it makes it really easy to remember how to run the project.

#!/usr/bin/env bash
iex -S mix phx.server

Other Scripts

Besides the above scripts which I have in nearly every project, I also have other scripts that show up in some of my projects:

bin/
  dev/
    doctor    # ensures the development environment is set up correctly
    format    # formats code for consistent style
    outdated  # checks which dependencies are outdated
    psql      # opens psql with the right database
    shipit    # updates, runs tests, and pushes
    start     # starts the server or app
    test      # runs tests
    update    # updates from git remote, updates dependencies, runs migrations
  prod/
    deploy    # deploys to production, or prints instructions for how to do it
    log       # shows production logs
    restart   # restarts servers
    scale     # adds or removes servers
    shutdown  # stops servers
    ssh       # logs into servers

Related Reading

Extreme Programming Practices

I’ve been practicing Extreme Programming (XP) for over twenty years. It’s an agile software development methodology that promotes taking good software practices to the extreme in order to provide maximum benefit.

For example, we know that writing tests is good; XP developers take testing to the extreme by writing tests for everything, and writing tests first. We know that code review is useful; XP developers take code review to the extreme by pair programming, which results in instant, continuous code review.

Other practices include daily stand-up meetings, weekly planning meetings, continuous integration, small releases, collective code ownership, and sustainable pace.

The Daily Diff

One practice that isn’t part of XP but that fits in nicely is the daily diff. I was first introduced to it by my friend and former boss Greg Woodward. It’s a 10-20 minute exercise that is performed daily and familiarizes the team with all the changes happening in the codebase. That familiarity is important when practicing collective code ownership. I can’t count the number of times I’ve said while programming, “hey, didn’t we see something in diff the other day…”

I’ve practiced daily diff primarily with teams of 6-10 people. With much larger teams, it would presumably be very time consuming, and few people would have enough context to understand most of what they were seeing. Larger teams are often split into sub-teams; it’s probably best for those sub-teams to have their own daily diffs.

Step 1: Gather Around A Computer

Each morning, the entire team gathers around a computer. I’ve used a few different configurations over the years: a 27" iMac connected to a second 27" monitor mirroring the iMac’s built-in screen, an iMac connected to an 80" 4K TV, and a laptop sharing its screen over Zoom with a bunch of remote developers.

Step 2: Choose A Driver

I’ve found it useful to have a different person running diff each day. My favorite way to choose a person is to write each person’s name on an index card and randomly pick one. The stack of index cards also comes in handy for quickly deciding who will kickoff the daily standup meeting, who will lead the weekly retrospective meeting, and for choosing pairs for the day by randomly choosing cards in groups of two.

Step 3: Open The Diff

Daily diff is about looking at all the code that was changed since the last time diff was done (usually yesterday). Some diff tools and editors can show a side-by-side diff of multiple commits to see all the changes at once. GitHub’s web diff can do this, but only shows the changes in each file rather than the entire file that was changed. I personally prefer the full-file diffs but GitHub’s web diff is simple to use and is often good enough.

When working on a team that is working on multiple projects at the same time, I diff each project separately.

I have found the daily diff to be a valuable part of my daily software development practice and I recommend that everyone try it. Like everything, it might not be a good fit or might need some adjustment for your particular situation.