DEV Community: James McMahon

TDD success/horror stories? #discuss 🙀

James McMahon — Fri, 22 Jan 2021 14:15:00 +0000

I'm curious what the dev.to community's experience is with TDD. Any success stories or horror stories?

Don't get stuck with out of date dependencies!

James McMahon — Wed, 20 Jan 2021 14:22:38 +0000

For Gradle

Use Latest Versions Plugin

Follow the instructions in the repo to add this plugin to your Gradle project, and viola, you should be able to run it with:

./gradlew useLatestVersions

This will update all your Gradle dependencies to the latest. You'll then need to manually run your tests to ensure everything look kosher.

For Node

updtr

updtr can be run as either a standalone command or a dev dependency. Once you have it installed, you can run:

updtr

In your project directory to update all your dependencies. What is awesome about updtr is that it will run your tests to ensure that each dependency updated successfully. Custom test commands can be specified by using the --test flag.

This also works for Yarn

Wrap Up

Those are the tools I've been using since I've been entrenched in the Java / Node stack. If you have a similar tool for your favorite stack, let me know in the comments below!

The No-Nonsense Guide to JVM 14 Memory on Kubernetes

James McMahon — Tue, 22 Sep 2020 16:00:33 +0000

This article is born out of frustration I had getting a direct answer to the question of how the modern JVM handles memory on containers. Let's get straight down to brass tacks.

The JVM as of JDK 14 has UseContainerSupport turned on by default. Here are some interesting defaults.

You can see these yourself by running,

docker run -m 1GB openjdk:14 java \
            -XX:+PrintFlagsFinal -version \
            | grep -E "UseContainerSupport | InitialRAMPercentage | MaxRAMPercentage | MinRAMPercentage | MinHeapFreeRatio | MaxHeapFreeRatio"

Outputs:

    double InitialRAMPercentage                      = 1.562500                                  {product} {default}
      uintx MaxHeapFreeRatio                         = 70                                     {manageable} {default}
     double MaxRAMPercentage                         = 25.000000                                 {product} {default}
      uintx MinHeapFreeRatio                         = 40                                     {manageable} {default}
     double MinRAMPercentage                         = 50.000000                                 {product} {default}
       bool UseContainerSupport                      = true                                      {product} {default}
  openjdk version "14.0.2" 2020-07-14
  OpenJDK Runtime Environment (build 14.0.2+12-46)
  OpenJDK 64-Bit Server VM (build 14.0.2+12-46, mixed mode, sharing)

MaxRAMPercentage is key here. The JVM defaults to 25%.

MinRAMPercentage and InitialRAMPercentage are tricky, this Stackoverflow answer is the best explanation I've read so far.

Here is a quick summary of that post:

InitialRAMPercentage - Used if InitialHeapSize and Xms are not set. In this case, if InitialHeapSize is 0. Source reference. I've never had much luck getting this one to work as expected.

MinRAMPercentage - Used if MaxHeapSize and Xmx are not set. In this case, not set meaning, default value for MaxHeapSize and Xmx absent. Source reference.

MaxRAMPercentage and Kubernetes

The observations below are based on some tests using a simple memory testing application I wrote.

You can set MaxRAMPercentage (and other JVM arguments) by editing your dockerfile:

ENTRYPOINT 
["java","-XX:InitialRAMPercentage=10","-XX:MaxRAMPercentage=75","-jar","/app.jar"]

Limits and requests are set using

  resources:
    limits:
      memory: 2Gi
    requests:
      memory: 2Gi

If no limit are set on the pod

The JVM will use up to the MaxRAMPercentage of the Node's memory. If the pod approaches the Node's memory limit, Kubernetes will kill the pod rather than throwing an OOM Exception.

Limits set on the container

For less than 100% `MaxRAMPercentage`

The JVM will use up to the MaxRAMPercentage of the limit. The pod is not killed, instead of throwing an OOM exception.

For 100% `MaxRAMPercentage`

The JVM will use up 100% of the memory limit. I saw this occasionally throw an OOM exception. With continued memory pressure Kubernetes will kill the pod.

What to set as max?

Assuming you are running a single container per pod, 25% as a default seems relatively low for MaxRAMPercentage. So what should you set it to for your application?

This question doesn't have a cut and dry answer. I can say 100% is a bad idea, but what's optimal is going to depend on the memory footprint of your application (with the JVM using system memory for Metaspace) and the container you are using.

I've heard some advice that states that you should leave at least 1gig for the OS at all times. I've also heard 75% recommended. Personally, we are using 80% for our application but I am also keeping an eye on and adjusting as needed. The truth is you are going to need to test out a few different configurations for your app and see what works for you.

What about requests?

Requests are an intresting one. I haven't seen them affect the start heap size of the JVM so they are just used for Node scheduling like any other K8 pod. The JVM tends to increase heap size and then never give it back, or very slowly give them back depending on your settings. (Heap reclamation is a large enough subject for another post entirely.)

Personally I've been setting requests to 50% of my limit. Depending on how fast your application is hitting that max heap I could also see setting this to 100% of the limit to help Kubernetes put your application on the approriate node.

That is the short version of a bunch of research, and as close to TLDR I could get for a complex topic. With the JDK 15 right around the corner, I will be looking to revise if there are any notable changes.

Any tips I missed? Let me know below.

Additional Resources / References

Note that some of these pertain to the JDK pre-14.

Add Keyboard Shortcuts to your Vue App ⌨️

James McMahon — Tue, 01 Sep 2020 22:17:00 +0000

I recently had to add some support for global key shortcuts in a Vue application I am working on. Vue has built-in support for listening to keys when you are in an input element. What is not supported directly are global shortcuts. For instance, if I am viewing an email in Gmail, I can hit 'a' to answer that email.

To accomplish this in Vue with either need to use low-level JavaScript event listeners or a plugin, like vue-shortkey. The approaches are not actually that different since vue-shortkey is, not surprisingly, just wrapping event listeners. It is straight forward to write your own event listener in a component so I didn't see a huge amount of value in using a plugin. There are a few blog posts covering event listeners in Vue already, but I am going to take a stab a showing a more complete example here, including how to test the component.

Implementing

Let's say we wanted to create a component that displays a message whenever the escape key is pressed.

Our Template block:

<div>{{ message }}</div>

Our Script block (Typescript):

import Vue from "vue";

export default Vue.component("Demo", {
  created() {
    window.addEventListener("keydown", this.escapeListener);
  },
  // make sure you remove the listener when the component is no longer visible
  destroyed() {
    window.removeEventListener("keydown", this.escapeListener);
  },
  data: function() {
    return {
      message: ""
    };
  },
  methods: {
    escapeListener(event: KeyboardEvent) {
      if (event.key === "Escape") {
        this.message = "Escape has been pressed";
      }
    }
  }
});

If you prefer to use class syntax, change the script block to the following:

export default class Demo extends Vue {
  private message = "";

  private created() {
    window.addEventListener("keydown", this.escapeListener);
  }

  private destroyed() {
    window.removeEventListener("keydown", this.escapeListener);
  }

  private escapeListener(event: KeyboardEvent) {
    if (event.key === "Escape") {
      this.message = "Escape has been pressed";
    }
  }
}

Testing

This is all well and good, but it was not immediately clear how you test this behavior. After a few false starts, I stumbled upon a Github issue thread with the solution.

The magic I was missing was to use the Vue testing utils attachToDocument option when mounting or shallow mounting the component under test. Once we attach our component to a document, we can use wrapper.trigger to simulate our keypresses.

describe("Demo.vue", function() {
  it("Displays a message when escape is pressed", function() {
    const wrapper = shallowMount(Demo, { attachToDocument: true });

    // the browser will add 'key' to the event,
    // but when testing we need to add it manually
    wrapper.trigger("keydown.esc", { key: "Escape" });

    expect(wrapper.text()).to.include("Escape has been pressed");

    // always make sure to destroy when using attachToDocument
    wrapper.destroy();
  });
});

And that is it, a straightforward way to test-drive our global shortcuts as we add them to our component.

Sentry with Spring Boot (The Better Way)

James McMahon — Mon, 24 Aug 2020 12:00:26 +0000

I wrote previously about our initial Sentry setup with Spring Boot, and let's just say mistakes were made.

Oh well, okay, it's not all bad, there is still some useful info there, which is why I am leaving it up, but there are some caveats.

You'll see a scary looking message about Sentry being disabled on boot up.
Errors / Warnings that happen at bootup will not be captured by Sentry.

TLDR

Just show me how to make it work.

build.gradle.kts:

implementation("io.sentry:sentry-logback:1.7.30")

sentry.properties: Put at the root of the Spring classpath

stacktrace.app.packages=com.mypackage

logback-spring.xml: Also put at root of the Spring classpath

<configuration>
    <include resource="org/springframework/boot/logging/logback/base.xml"/>
    <appender name="SENTRY" class="io.sentry.logback.SentryAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>WARN</level>
        </filter>
    </appender>

    <root level="INFO">
        <appender-ref ref="CONSOLE"/>
        <appender-ref ref="FILE"/>
        <appender-ref ref="SENTRY"/>
    </root>
</configuration>

EDIT: The configuration has changed in later versions of the Sentry library, this is the same config updated for 3.2.0.

<configuration>
    <include resource="org/springframework/boot/logging/logback/base.xml"/>
    <appender name="SENTRY" class="io.sentry.logback.SentryAppender">
        <minimumEventLevel>WARN</minimumEventLevel>
    </appender>

    <root level="INFO">
        <appender-ref ref="CONSOLE"/>
        <appender-ref ref="FILE"/>
        <appender-ref ref="SENTRY"/>
    </root>
</configuration>

Environment Variables

- name: SENTRY_ENVIRONMENT
value: <enviroment>
- name: SENTRY_DSN
value: "<my-dsn>"

Set the environment variables on a per deployment basis, which is going vary depending on your infrastructure. (We have ours as a Helm deployment value).

To disable Sentry, omit the SENTRY_DSN environment variable.

The longer explanation

So when I initially setup Sentry, I very much wanted to store my Sentry configuration alongside my Spring Boot project configuration. As you may have noticed above, I've entirely abandoned that approach, which I am slightly sad about since I like having configuration in one place.

So what went wrong, well let's look at the two issues we had:

You'll see a scary looking message about Sentry being disabled on boot up.

Specifically this error,

*** Couldn't find a suitable DSN, Sentry operations will do nothing! See documentation: https://docs.sentry.io/clients/java/ ***

But then you'll start seeing errors going to Sentry just fine. What the heck? This is connected to the next issue.

Errors / Warnings that happen at bootup will not be captured by Sentry.

While you will see errors go to Sentry, it will omit errors at bootup. Why? Because the Spring configuration isn't loaded until the Spring Application Context is created, which means that Sentry misses the boat.

I won't keep you in suspense, here is what is happening:

Logback boots up.
The Sentry Logback appender boots up.
Sentry finds no configuration, in either properties or the runtime environment.
It logs a missing DSN warning.
Spring Boot boots.
The Sentry Spring Boot starter configures Sentry.
Sentry will now be able to capture errors.

So if you care about capturing errors on bootup, sentry-spring-boot-starter isn't really doing anything for you. In fact, with the configuration above, all you need is sentry-logback as a dependency.

Wrap Up

So the choices for using Sentry with Spring Boot are the following:

Use the logback dependency and capture errors both on startup and runtime but use environmental / properties for configuration.
Use the Spring Boot starter and capture errors only at runtime but be able to use application.yaml for configuration. If you want to capture logs, you'll need to put off with a scary-looking warning at startup.

If the latter sounds preferable, check out my first article. But the method I'd recommend is above, even if the configuration options are worse.

Once again, I hope this was helpful. I've been staring Sentry for a bit now, so if you have any questions, feel free to ask below.

Sentry with Spring Boot

James McMahon — Tue, 07 Jul 2020 23:28:18 +0000

After writing this article I've revised my approach. See this follow up article for details. The approach below still works, with some caveats.

We are trying out Sentry for error alerting at Focused Labs, and I wanted to set it up in my Spring Boot backend. For the most part, Sentry has been super easy to add to a project, but I hit a few little snags with the Spring Boot integration that I wanted to share with the community.

I'll keep this short, this is what I ended up with:

build.gradle.kts:

implementation("io.sentry:sentry-spring-boot-starter:1.7.30")
implementation("io.sentry:sentry-logback:1.7.30")

In some scenarios, this may lead to duplicate errors. The official docs warn against including both sentry-spring (which is pulled in by sentry-spring-boot-starter) and sentry-logback. Which makes sense since the Spring integration with Sentry is handling exceptions and sending them to Sentry and the Logback integration is watching logs, and then sending them to Sentry.

We are using GraphQL in our backend, so the sentry-spring behavior wasn't catching our exceptions since they are exclusively catching errors in the context of an MVC controller. Still, potentially, an exception would both be logged and caught by the Sentry exception handler, resulting in a duplicate error. If this becomes an issue, I'll have to revisit my dependencies.

This is why I am bothering with sentry-spring-boot-starter

application.yaml:

---
sentry:
  dsn: '<my-dsn>'
  stacktrace:
    app-packages:
      - com.mypackage
spring:
  profiles:
    active: dev
---
spring:
  profiles: dev
sentry:
  enabled: false
  environment: dev
---
spring:
  profiles: production
sentry:
  environment: production

Sweet sweet YAML.

Thanks to the configuration support in sentry-spring-boot-starter I can just locate my Sentry configuration right next to the rest of my Spring Boot configuration.

logback-spring.xml:

<configuration>
    <include resource="org/springframework/boot/logging/logback/base.xml"/>
    <appender name="SENTRY" class="io.sentry.logback.SentryAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>WARN</level>
        </filter>
    </appender>

    <root level="INFO">
        <appender-ref ref="CONSOLE"/>
        <appender-ref ref="FILE"/>
        <appender-ref ref="SENTRY"/>
    </root>
</configuration>

By using include here, I am able to defer to the default Spring Boot log configuration and only override what I absolutely need to. In this case, adding an additional appender to the root logger.

And that's it! It looks straight forward when laid out here, but took a few iterations to get everything working. Hopefully, this helps other people out with the same process.

Vue Router Testing Strategies

James McMahon — Thu, 02 Jan 2020 16:41:31 +0000

Recently I was playing with some techniques for testing the Vue Router in my app. The Vue Testing Handbook has some excellent advice for the basics, but I wanted to take some time to do a deep dive on various techniques and how you can evolve your testing patterns to meet the needs of your app.

Why

Why should we care about testing our Vue Router?

If our Router looks like this,

export default new Router({
    mode: "history",
    base: process.env.BASE_URL,
    routes: [
        {
            path: "/",
            component: Home
        },
        {
            path: "/about",
            component: About
        }
    ]
});

You might not think you need to test it, and you are probably right. The Router in it's purest form is configuration, so tests at this point are limited to verifying our configuration.

But as our Router starts to grow and we start attaching behavior to it, then testing and test driving that behavior becomes reasonable and efficient.

How

So how do we go about testing behavior? Specifically, the behavior that comes from Navigation Guards? The Testing Handbook has some advice. They recommend de-coupling the guard function from the Router and testing that a mock inside the guard function is invoked.

That handbook is full of excellent testing strategies, and in the cache bursting scenario they laid out, this approach makes sense, but what if I want my guard to control my resulting navigation?

For this scenario, I want to add the following behavior to the Router,

I have a login in page everyone can access
My other routes require the user to be logged in. If they are not and try and access those routes, they are redirected back to the login screen.

Let's take a TDD approach and start with the tests to drive our implementation:

describe("/login", () => {
    it("routes to the login page", async () => {
        const router = createRouter();
        await router.push("/login");
        expect(router.currentRoute.fullPath).to.eq("/login");
    });
});

Now our implementation, notice that I've changed the Router export from configuration object to a function that creates the configuration. This change makes it easier to create a new instance on per test basis and avoid cross-contamination due to global state:

export const createRouter = () =>
    new Router({
        mode: "history",
        base: process.env.BASE_URL,
        routes: [
            {
                path: "/login",
                component: Login
            }
        ]
    });

Super easy to implement. However, it feels like our basic scenario above where we are just checking configuration. Let's add some more interesting behavior:

describe("/", () => {
    it("can only be accessed by a logged in user", async () => {
        const loggedOutRouter = createRouter({ loggedIn: false });
        await loggedOutRouter.push("/");
        expect(loggedOutRouter.currentRoute.fullPath).to.eq("/login");

        const loggedInRouter = createRouter({ loggedIn: true });
        await loggedOutRouter.push("/");
        expect(loggedOutRouter.currentRoute.fullPath).to.eq("/");
    });
});

and here is the implementation:

export const createRouter = authContext => {
  const router = new Router({
    mode: "history",
    base: process.env.BASE_URL,
    routes: [
      {
        path: "/login",
        component: Login
      },
      {
        path: "/",
        component: Home,
        meta: { requiresAuth: true }
      }
    ]
  });

  router.beforeEach((to, from, next) => {
    if (to.meta.requiresAuth && !authContext.loggedIn) {
      next("/login");
    } else {
      next();
    }
  });

  return router;
};

Wait! Our tests still don't pass. Instead, we get this mysterious error:

router /

can only be accessed by a logged in user:

Error: Promise rejected with no or falsy reason

What is happening is that when we redirect to the next("/login") we trigger an abort, which, if we are using the Promise API for router.push, rejects the Promise. So are options are to switch to the older, non-Promise API by passing in some empty handler functions, like so:

loggedOutRouter.push("/", () => {}, () => {});

or swallow the rejected Promise:

await loggedOutRouter.push("/").catch(() => {})

All things being equal, I would prefer to keep Promises and asynchronicity out of our tests if possible as they add another layer of complexity. So let's go ahead and use the non-Promise API. Adding two no-op functions to each call to push is going to get old fast, so let's make a helper function:

const push = (router, path) => {
  const noOp = () => {};
  router.push(path, noOp, noOp);
};

Now we write our push as:

describe("/", () => {
  it("can only be accessed by a logged in user", () => {
    const loggedOutRouter = createRouter({ loggedIn: false });
    push(loggedOutRouter, "/");
    expect(loggedOutRouter.currentRoute.fullPath).to.eq("/login");

    const loggedInRouter = createRouter({ loggedIn: true });
    push(loggedInRouter, "/");
    expect(loggedInRouter.currentRoute.fullPath).to.eq("/");
  });
});

Much better, both in terms of succinctness and readability.

Looking at this test suite, I am tempted to delete that login test as it doesn't seem to provide much value. But let's think about what we are building for a second. Does it make sense for a user who is already logged in to be able to see the login screen? Let's make sure that can't happen:

describe("/login", () => {
  it("routes to the login page if not logged in", () => {
    const loggedOutRouter = createRouter({ loggedIn: false });
    push(loggedOutRouter, "/login");
    expect(loggedOutRouter.currentRoute.fullPath).to.eq("/login");

    const loggedInRouter = createRouter({ loggedIn: true });
    push(loggedInRouter, "/login");
    expect(loggedInRouter.currentRoute.fullPath).to.eq("/");
  });
});

And our implementation:

router.beforeEach((to, from, next) => {
  if (to.meta.requiresAuth && !authContext.loggedIn) {
    next("/login");
  } else if (to.path === "/login" && authContext.loggedIn) {
    next("/");
  } else {
    next();
  }
});

This block could be hairy in the future as we add additional conditions, but for now, it is reasonably straight forward, and our passing tests allow us to refactor as the need arises.

Let's add some more behavior to our Router. Let's say we have a component that needs some props:

describe("/gizmos", () => {
  it("add id as a prop to the route", () => {
    const router = createRouter({ loggedIn: true });
    router.push("/gizmos");

    const matchedRoute = router.currentRoute.matched[0];
    const props = matchedRoute.props.default;
    expect(props).to.eql({
      sampleProp: true
    });
  });
});

// implementation - new route
{
  path: "/gizmos",
  component: Gizmos,
  props: { sampleProp: true }
}

Pretty straightforward, aside from the nested objects needed to get to the actual props object. That test feels less readable because of that logic; let's extract it out to a helper function.

describe("/gizmos", () => {
  it("adds a sample prop to the route", () => {
    const router = createRouter({ loggedIn: true });
    push(router, "/gizmos");
    expect(currentProps(router)).to.eql({
      sampleProp: true
    });
  });

  const currentProps = router => {
    const matchedRoute = router.currentRoute.matched[0];
    return matchedRoute.props.default;
  };
});

That feels more readable and straightforward to me.

What about router-view?

The testing handbook lays out another scenario and demonstrates testing against a top-level App component using router-view. This strategy sounds pretty good as we aren't currently directly testing what component is loaded by our Router.

So say we have a component named App.vue that looks like the following:

<template>
  <div>
    <router-view />
  </div>
</template>

Let's rewrite login tests to test against this component.

describe("App.vue", () => {
  it("routes to the login page if not logged in", () => {
    const loggedOutRouter = createRouter({ loggedIn: false });
    const loggedOutApp = mount(App, { router: loggedOutRouter });
    push(loggedOutRouter, "/login");
    expect(loggedOutApp.find(Login).exists()).to.eq(true);

    const loggedInRouter = createRouter({ loggedIn: true });
    const loggedInApp = mount(App, { router: loggedInRouter });
    push(loggedInRouter, "/login");
    expect(loggedInApp.find(Login).exists()).to.eq(false);
  });
});

const push = (router, path) => {
  const noOp = () => {};
  router.push(path, noOp, noOp);
};

We could potentially rewrite our entire test suite this way, let's examine the trade-offs. Tests pointed at the App component are concerned with more moving pieces, because they now need to mount said component and attach the router to it. On the other hand, this approach is verifying that we can load the component that is routed to. Depending on the needs of your app and the complexity of your Router, either approach could be valid.

A scenario where testing through a component is beneficial is when we are dealing with props. Let's say we added an id to our gizmos route and put that id in our props as described in the Vue Router docs. Here is what the tests and implementation looks-like without using the App component.

it("adds the gizmo id as a prop to the route", () => {
  const router = createRouter({ loggedIn: true });
  push(router, "/gizmos/123");
  expect(currentProps(router).id).to.eq("123");
});

const currentProps = router => {
  const currentRoute = router.currentRoute;
  const props = currentRoute.matched[0].props;
  const propsFunction = props.default;
  return propsFunction(currentRoute);
};

// adjusted gizmos route implementation
{
  path: "/gizmos/:id",
  component: Gizmos,
  props: route => ({ id: route.params.id, sampleProp: true })
}

This test is working, but it isn't great. It isn't actually verifying the id is passed in. Instead, it is verifying that the props function resolves correctly, which requires replicating the circumstances under how Vue Router is invoking the props function. Therefore, reading this test now requires a good understanding of how Vue Router works, which is less then ideal when you are onboarding new Developers to this codebase or if you forget the internal details of Vue Router's behavior.

Let's look at how this test looks written against the App component.

it("adds the gizmo id as a prop to the route", () => {
  const router = createRouter({ loggedIn: true });
  const app = mount(App, { router });

  push(router, "/gizmos/123");

  expect(app.find(Gizmos).props().id).to.eq("123");
});

This approach looks a little more straightforward. The downside is that now multiple components, both App and Gizmos, are pulled into the testing of our Router behavior. That means these tests are going to be more likely to break if either of those components changes, which can be a good thing, but overall our tests are going to be more complicated.

Choosing the right testing strategy for your Application requires weighing the pros and cons of both approaches. Testing, like software engineering in general, is not about one size fits all solutions.

Conclusion

Hopefully, it is now clear how you would test a Vue Router with a few different strategies, and you can choose the right approach for your project.

Creating Serverless Functions using TDD

James McMahon — Thu, 02 Jan 2020 16:28:00 +0000

Regardless of where you are in the industry, there is a good chance that Serverless functions are a topic you've seen brought up on Reddit, Hackernews, a local Meetup, or where ever you find two programmers talking. If you have never worked with them before, they can sound intimidating; yet another stack to learn or some deep Dev Ops magic. The beauty of Serverless functions is they make things easier by introducing a layer of abstraction between the code you want to run and the servers running the code. That's right, despite them being called Serverless, they most definitely do run on servers, just not servers you explicitly know or care about.

Having one less thing to worry about always sounds great to me. Granted, it is not all sunshine and roses. Like any engineering tool, there are costs and trade-offs involved, which I am not going to cover in this post. Generally, I'd say this feels like an abstraction that is needed in the industry at large, and I wouldn't be surprised to see more and more engineers apply a serverless approach to an increasingly varied set of domains.

If you find yourself in a position to start to use them, you may be at a loss as to where to begin. How do you structure your code? How do you ensure your code is high quality? The same questions you ask yourself when engaging with any new technology. The answer is, as it is to any interesting question, it depends.

In this post, I am going to lay at a reasonable starting approach that can be adjusted to your specific needs as you become more familiar with the technology. Using a TDD approach and a familiar backend architecture, I am going to guide you through a simple scenario.

Firebase

There are many different platforms out there that support Serverless Functions, but lately, I've been using Firebase's Cloud Functions on client projects. The Firebase ecosystem is exciting, and the more I learn about it, the faster, I feel like I can deliver software to my clients, so it's all worth learning about, but for today, let's focus on Firebase's functions.

Here is what a basic Hello World function looks like:

import * as functions from "firebase-functions";

export const helloWorld = functions.https.onRequest((request, response) => {
  response.send("Hello from Firebase!");
});

Pretty straight forward, the firebase-functions API works by registering functions to handle a request, something that should not be too surprising for those who have used Express or Hapi in the past.

One of the cool things about Firebase is the ease at which you can integrate with other technologies on the platform. Firebase supports Google's Cloud Storage. Here is how you would write a function to listen to a bucket and do something when a file is uploaded:

export const helloStorage = functions.storage
  .object()
  .onFinalize((objectMetadata: ObjectMetadata, context: EventContext) =>
    console.log("Hello from Firebase storage!")
  );

I'm using Typescript to get a better view of what the Firebase API is going to send my function. Both ObjectMetadata and EventContext are rather large, so I am not going to post the full types here. The TLDR is that ObjectMetadata will give you details about the object that just finalized (or uploaded) and EventContext, gives you auth context, a timestamp, etc. This simple API can be used as a launching point to solve some interesting problems. Coupled with Firebase's rather amazing client-side API, we can kick off whatever behavior we need from a simple file upload.

Diving In

Let's work together on solving a problem using the tools Firebase is giving us. If you are interested in following along, I highly recommend following the getting started docs for Firebase Functions. You ultimately want to spin up a blank project with Functions, Firestore, and Storage configured. Following along, you can add code and libraries as I mention them below.

Problem

Currently, Video Game review aggregators, like OpenCritic and MetaCritic, are in the midst of introspecting about the best titles over the last decade. Let's write some code to help them out.

Let's say I have a CSV file that looks like this,

game,publisher,year,rating
Slay The Spire,Mega Crit Games,2019,89
Luigi's Mansion,Nintendo,2019,86
Super Mario Maker 2,Nintendo,2019,88
Red Dead Redemption 2,Rockstar Games,2018,96
God of War,Sony Interactive Entertainment,2018,95
Super Mario Odyssey,Nintendo,2017,97
Persona 5,Atlus,2017,94

and I want to create a screen of all high ranking games grouped by years,

Let's not worry about the UI side of things. Let's assume that if we can get into the database, we can revisit it later and write a UI on top of it. Let's use Firebase's own Cloud Firestore as our database since it is going to plug nicely into the Firebase infrastructure. Firestore is a NoSQL database that has a few unique qualities that are out of scope for this blog post, but it's pretty great and worth reading up on. We are also going to use Typescript for more transparent code samples and because it is awesome.

To store our Games Of The Year data, let's plan on creating a single document in Firestore. The UI will then only need to retrieve this document to be able to display a nice retrospective of the last 10 years of Video Games to the user.

At a high level, we need to do the following:

Read in a CSV file
Transform it into a JSON document
Save it to our database
Test all of that to the best of our abilities

Testing Approach

For this example, we may be tempted to write a test that tests all the way through the functions, feeding in a CSV, and then checking the database for the expected result.

While I think that sounds reasonable, I know from experience that Firebase Integration Tests are not super easy to write with the isolation needed to run them in an automated fashion. While Google has a function emulator, it has its own nuances and challenges. Another approach is to set up a separate Firebase environment just for tests, which also has some significant downsides, especially if you are working on a team.

For the purposes of this blog, let's scope everything down and focus on Unit Tests. The Unit Tests we write are going to run ultra-fast, be small and simple, require no external dependencies, and be excellent at covering error conditions and corner cases. Let's save talking about Integration Tests for another post.

Thinking it through

When we start thinking about Unit Tests, we have to start thinking about how our application is architectured and how our responsibilities are layered. We need to divide these responsibilities into pieces of code that are essentially our units to test.

Let's take an approach that should be familiar to most people who have prior experience with backend code. Let's divide our architecture into 3 tiers:

The Controller Layer - Responsible for adapting incoming messages from our platform (Firebase) into our domain
The Service Layer - Where our business logic lives.
The Repository Layer - Takes messages from our domain and saves them to our database.

In addition to this, our index.ts file is going to be responsible for registering our logic with the Firebase function API, creating each of these layers, and composing them correctly.

This 3 tier approach isn't the only way we can approach Serverless Functions, but it does represent a reasonable starting point and a smooth transition from other backend frameworks.

While I typically drive interfaces out as I develop my tests, for clarity, let's lay out the interface for each of our layers in advance:

export interface GamesOfTheYearController {
  create(objectMetadata: ObjectMetadata): Promise<void>;
}

export interface GamesOfTheYearService {
  add(games: Game[]): Promise<void>;
}

export interface GamesOfTheYearRepository {
  add(gamesOfTheYear: GamesOfTheYear): Promise<void>;
}

Typescript is useful here as we can focus on the messages that each layer is responsible for. First of all, each layer is returning a void, but it is a void wrapped in a Promise. This means that though we aren't returning anything, there are two signals that our layers are passing up.

The task is complete.
The task was successful or unsuccessful.

So even though we are dealing with void, these messages have a lot of information to convey. Additionally, keep in mind that each layer is calling the one underneath it, so they are also implicitly responsible for sending off that message as well.

Now let's turn our attention to the message that each interface receives:

Controller

Our controller is receiving a message with ObjectMetadata, which is the type defined by Firebase that we talked about previously.

Service

Our service takes a Game array message. What is this Game type? We haven't defined it yet, but it may be reasonable to define it so it matches our CSV file.

So:

game,publisher,year,rating
Slay The Spire,Mega Crit Games,2019,89
Luigi's Mansion,Nintendo,2019,86

Becomes:

interface Game {
  game: string;
  publisher: string;
  rating: number;
  year: number;
}

Repository

Moving on to our repository, which takes another new type, GamesOfTheYear. This layer is where we need to start thinking about what we want to store in our database. We want a set of years, which each year having multiple games attached to it:

export interface GameForYear {
  game: string;
  publisher: string;
  rating: number;
}

export interface GamesOfTheYear {
  years: {
    [key: number]: GameForYear[];
  };
}

Above I am using a plain old Javascript object, which Firestore refers to as a map as our set. This set allows us to maintain an association between a year and the games that came out during it.

So why not just store our Game type directly into the database? Keep in mind; we want to be able to return a single document to our UI that has all the information we need. So while we could store an array of Game's into our Firestore document, our UI is now going to be responsible for parsing all those rows into an object that makes sense to display. Let's save ourselves (or someone else) some work and have our Serverless Function store this data in a format that is going to be seamless for our UI to work with.

Testing and implementing

Controller

Let's start at the top and think of what our controller is responsible for,

Taking in a CSV
Telling our service layer to add those rows in that CSV

Let's drive that functionality with a test:

// For the purposes of these examples, I am using Mocha Chai for testing and SafeMock for mocking.

it("adds a GamesOfTheYear", async function() {
  // GameOfTheYearService is my interface we defined above
  const mockGamesOfTheYearService = SafeMock.build<GamesOfTheYearService>();
  when(mockGamesOfTheYearService.add).resolve();
  // CloudStorageGamesOfTheYearController is my implementation of that interface
  const controller = new CloudStorageGamesOfTheYearController(
    mockGamesOfTheYearService
  );

  // since we are returning a void there is nothing to capture here
  // but we do want to ensure the method to be done before asserting, hence await
  await controller.create(
    createMockStorageObject({
      bucket: "bucket",
      name: "filename"
    })
  );

  const expectedGames = [
    {
      game: "Slay The Spire",
      publisher: "Mega Crit Games",
      year: 2019,
      rating: 89
    },
    {
      game: "God Of War",
      publisher: "Sony Interactive Entertainment",
      year: 2018,
      rating: 95
    }
  ];
  verify(mockGamesOfTheYearService.add).calledWith(expectedGames);
});

// helper to create the message coming from the Firebase API
const createMockStorageObject = (
  overrides: Partial<ObjectMetadata> = {}
): ObjectMetadata =>
  ({
    bucket: "test-bucket",
    contentType: "text/csv",
    name: "test-file",
    metadata: {
      templateName: "test-template"
    },
    ...overrides
  } as ObjectMetadata);

This result is not too dissimilar from how the tests for an HTTP based controller would look in a traditional backend.

There is a wrinkle here; the Firebase API is only going to give us a filename. It is up to us to download the file to whatever instances this function is running on. We could say this unit of code is also responsible for downloading as well. However, due to a dependency on the Firebase APIs, we would then need to bring in an external dependency whenever we ran this test. How can we avoid this?

What if we followed the approach we have taken so far and put that functionality behind an interface? Essentially, we segment the difficult to test behavior away from the current unit we are testing.

export interface FileService {
  // download takes in where it needs to download from and returns a string containing the downloaded file path
  download(location: string, filePath: string): Promise<string>;
}

Now we can adjust our tests and add in one more mock to our setup, right before we create our controller:

const mockFileService = SafeMock.build<FileService>();
when(mockFileService.download("test-bucket", "test-filename")).resolve(
  "./tests/GamesOfTheYear/fixtures/two-games.csv"
);
const controller = new CloudStorageGamesOfTheYearController(
  mockFileService,
  mockGamesOfTheYearService
);

This mock looks a little different from the mockGamesOfTheYearService we did previously. In this case, we are taking in two parameters and return our filename if, and only if, these two parameters match. To make sure that happens, let's change the ObjectMetadata that we are invoking our controller with to one that matches our mock:

await controller.create(
  createMockStorageObject({
    bucket: "test-bucket", // previously "bucket"
    name: "test-filename" // previously "filename"
  })
);

We also need to add a local file fixture, two-games.csv:

game,publisher,year,rating
Slay The Spire,Mega Crit Games,2019,89
God Of War,Sony Interactive Entertainment,2018,95

This file is loaded from our local filesystem and used to ensure that our function can load a file and read it.

Our tests are now in an excellent place to drive our implementation. Let's run our tests first to make sure we haven't messed something up and that we have a red test.

FirebaseGamesOfTheYearController 1) adds a GamesOfTheYear

0 passing (15ms)
1 failing

FirebaseGamesOfTheYearController
adds a GamesOfTheYear:

Error: add was not called with: (Array[{"game":"Slay The Spire","publisher":"Mega Crit Games","year":2019,> "rating":89},{"game":"God Of War","publisher":"Sony Interactive Entertainment","year":2018,"rating":95}])
- expected - actual

-[]
+[

- [
- {
-      "game": "Slay The Spire"
-      "publisher": "Mega Crit Games"
-      "rating": 89
-      "year": 2019
- }
- {
-      "game": "God Of War"
-      "publisher": "Sony Interactive Entertainment"
-      "rating": 95
-      "year": 2018
- }
- ]
  +]

Awesome! Our test is failing exactly like we want.

Let's implement our controller:

// 'cvstojson' is an NPM module to load our CSV
import * as csvtojson from "csvtojson";
import { FileService } from "./FileService";
import { GamesOfTheYearService } from "./GamesOfTheYearService";
import { ObjectMetadata } from "firebase-functions/lib/providers/storage";

export class CloudStorageGamesOfTheYearController
  implements GamesOfTheYearController {
  constructor(
    private readonly fileService: FileService,
    private readonly gamesOfTheYearService: GamesOfTheYearService
  ) {}

  async create(objectMetadata: ObjectMetadata): Promise<void> {
    const filePath = await this.fileService.download(
      objectMetadata.bucket,
      objectMetadata.name!
    );

    const rows = await csvtojson({ checkType: true }).fromFile(filePath);
    await this.gamesOfTheYearService.add(rows);
  }
}

If we re-run our tests they should now pass!

You'll notice I needed to refer to objectMetadata.name with a !. This is due to the type being possibly undefined. To me, this suggests we have another case to handle with a test. Going higher level, I want to handle the remaining cases in my tests:

If the objectMetadata doesn't contain a name, I should throw a clear error
If the file given to my controller is CSV, I should throw another error

These are both error cases. So far, we have only covered our "Happy Path," which is when the function gets everything it needs, and everything goes according to plan. What makes programming difficult is usually handling error cases, and as I mentioned before, Unit Tests are great at that. If we go ahead and test those two scenarios and implement them, we end up with the following:

// tests
describe("FirebaseGamesOfTheYearController", function() {
  before(function() {
    // using the library 'chai-as-promised' to help with better assertions
    chai.use(chaiAsPromised);
  });

  it("adds a GamesOfTheYear", async function() {
    // snip, this is the same as above
  });

  it("throws an exception if the file is not a csv", function() {
    const notCsvObject = createMockStorageObject({
      contentType: "not-csv"
    });
    const controller = new CloudStorageGamesOfTheYearController(
      SafeMock.build<FileService>(),
      SafeMock.build<GamesOfTheYearService>()
    );

    return expect(controller.create(notCsvObject)).to.be.rejectedWith(
      "File type is not csv"
    );
  });

  it("throws an exception if there no filename", function() {
    const noNameFileObject = createMockStorageObject({
      name: undefined
    });
    const controller = new CloudStorageGamesOfTheYearController(
      SafeMock.build<FileService>(),
      SafeMock.build<GamesOfTheYearService>()
    );

    return expect(controller.create(noNameFileObject)).to.be.rejectedWith(
      "Can not resolve filename"
    );
  });
});

// full implementation
export class CloudStorageGamesOfTheYearController
  implements GamesOfTheYearController {
  constructor(
    private readonly fileService: FileService,
    private readonly gamesOfTheYearService: GamesOfTheYearService
  ) {}

  async create(objectMetadata: ObjectMetadata): Promise<void> {
    if (!objectMetadata.name) {
      throw new Error("Can not resolve filename");
    }

    if (objectMetadata.contentType !== "text/csv") {
      throw new Error("File type is not csv");
    }

    const filePath = await this.fileService.download(
      objectMetadata.bucket,
      objectMetadata.name
    );

    const rows = await csvtojson({ checkType: true }).fromFile(filePath);
    await this.gamesOfTheYearService.add(rows);
  }
}

All our tests should now be green. At this point, we have a complete controller. There are two ways we can go now, either implement FileService or GameOfTheYearService. Let's do the latter first.

Service

We would test-drive our service exactly like we did our controller and end up with the following:

Tests:

describe("GamesOfTheYearServiceImpl", function() {
  it("add saves games of the year", async function() {
    const mockRepository = SafeMock.build<GamesOfTheYearRepository>();
    when(mockRepository.add).resolve();
    const gamesOfTheYearService = new GamesOfTheYearServiceImpl(mockRepository);

    await gamesOfTheYearService.add([
      {
        game: "Luigi's Mansion",
        publisher: "Nintendo",
        rating: 86,
        year: 2019
      },
      {
        game: "Red Dead Redemption 2",
        publisher: "Rockstar Games",
        rating: 96,
        year: 2018
      }
    ]);

    const expectedGamesOfTheYear = {
      years: {
        2019: [
          {
            game: "Luigi's Mansion",
            publisher: "Nintendo",
            rating: 86
          }
        ],
        2018: [
          {
            game: "Red Dead Redemption 2",
            publisher: "Rockstar Games",
            rating: 96
          }
        ]
      }
    };
    verify(mockRepository.add).calledWith(expectedGamesOfTheYear);
  });

  it("sorts games of the year by score", async function() {
    const mockRepository = SafeMock.build<GamesOfTheYearRepository>();
    when(mockRepository.add).resolve();
    const gamesOfTheYearService = new GamesOfTheYearServiceImpl(mockRepository);

    await gamesOfTheYearService.add([
      {
        game: "Luigi's Mansion",
        publisher: "Nintendo",
        rating: 86,
        year: 2019
      },
      {
        game: "Resident Evil 2",
        publisher: "Capcom",
        rating: 92,
        year: 2019
      }
    ]);

    const expectedGamesOfTheYear = {
      years: {
        2019: [
          {
            game: "Resident Evil 2",
            publisher: "Capcom",
            rating: 92
          },
          {
            game: "Luigi's Mansion",
            publisher: "Nintendo",
            rating: 86
          }
        ]
      }
    };
    verify(mockRepository.add).calledWith(expectedGamesOfTheYear);
  });
});

Implementation:

import _ = require("lodash");

export class GamesOfTheYearServiceImpl implements GamesOfTheYearService {
  constructor(private readonly repository: GamesOfTheYearRepository) {}

  private static reduceYears(result: GamesOfTheYear["years"], game: Game) {
    const key = game.year;
    const years = result[key] || (result[key] = [] as GameForYear[]);
    years.push({
      game: game.game,
      publisher: game.publisher,
      rating: game.rating
    });
    return result;
  }

  async add(games: Game[]): Promise<void> {
    await this.repository.add({
      years: _(games)
        .orderBy("rating", "desc")
        .reduce<GamesOfTheYear["years"]>(
          GamesOfTheYearServiceImpl.reduceYears,
          {}
        )
    });
  }
}

Our business logic right now is a simple data transformation. Unlike our controller, there are no other responsibilities to segment out in our business logic, so our tests are self-contained.

The bits that are harder to test

FileService

Now let's go back up a level to our FileService that we need for our controller. This is where we get into parts of our Serverless Function that become difficult to test in isolation. Since we don't currently have a good way to test drive this implementation with a Unit Test, let's make a concession and say FileService won't be tested:

import * as admin from "firebase-admin";
// tmp is the 'tmp' npm library
import * as tmp from "tmp";

export class CloudStorageFileService implements FileService {
  public async download(location: string, filePath: string): Promise<string> {
    const bucket = admin.storage().bucket(location);
    const tempLocalFile = tmp.tmpNameSync();
    await bucket.file(filePath).download({ destination: tempLocalFile });
    return tempLocalFile;
  }
}

It is kind of a bummer that we can't test this file due to the entanglement with Firebase.

We could mock out that admin import, but at that point, we are diving pretty heavily into the anti-pattern of Mocking What You Don't Own. Put succinctly; we are going to make guesses of how this code we don't own, admin, is implemented to test it. If we make the wrong guess, our test is useless, and if Google ever changes that code to make our previous guess wrong, our test is not going to tell us we have something wrong.

This is a situation where we want to integrate test this piece of code, but let's leave that for another blog post and another day.

One thing that makes me feel pretty good about not testing here is the lack of any real logic. It has no branching paths or complex behavior. There are two ways this code can behave,

It works.
Or it blows up due to an environmental issue.

Since we kept the interface verbs super simple, the resulting implementation is simple as well. If we have code that we can't test, this is the approach we want to take. We want to move complexity and branching logic out of untested code and into a testable layer.

Once we deploy this code, this function will either not work or work, and if it works, it will continue to work due to lack of logic. That one successful manual run we perform with cover all the logic paths.

Repository and index.ts

To implement our remaining functionality, we once again hit a situation where we can't Unit Test. Let's try and follow the example we set with our FileService and keep branching logic to a minimum.

export class FirestoreGamesOfTheYearRepository
  implements GamesOfTheYearRepository {
  async add(gamesOfTheYear: GamesOfTheYear): Promise<void> {
    await admin
      .firestore()
      .collection("gamesOfTheYear")
      .add(gamesOfTheYear);
  }
}

Mission accomplished, there is even less logic in our repository than in our FileService.

Our index is equally as simple.

import * as functions from "firebase-functions";
import { FirestoreGamesOfTheYearRepository } from "./GamesOfTheYear/GamesOfTheYearRepository";
import { GamesOfTheYearServiceImpl } from "./GamesOfTheYear/GamesOfTheYearService";
import { CloudStorageGamesOfTheYearController } from "./GamesOfTheYear/GamesOfTheYearController";
import { CloudStorageFileService } from "./GamesOfTheYear/FileService";
import { ObjectMetadata } from "firebase-functions/lib/providers/storage";
import * as admin from "firebase-admin";

// Initialize our Firebase config
admin.initializeApp();

// Construct our dependencies
const gamesOfTheYearRepository = new FirestoreGamesOfTheYearRepository();
const gamesOfTheYearService = new GamesOfTheYearServiceImpl(
  gamesOfTheYearRepository
);
const fileService = new CloudStorageFileService();
const gamesOfTheYearController = new CloudStorageGamesOfTheYearController(
  fileService,
  gamesOfTheYearService
);

// Register our function with the Firebase APIs
export const importGamesOfTheYear = functions.storage
  .object()
  .onFinalize((objectMetadata: ObjectMetadata) =>
    gamesOfTheYearController.create(objectMetadata)
  );

You can go and deploy our function to Firebase using npm deploy. After deploying, upload a CSV file to your project's default storage bucket, and you should then see a new entry in your database representing the transformed file.

And there we have it; a simple but tested Serverless Function. We've kept all our logic isolated from the bits we can't test yet, and there is an excellent chance that this works the first time we deploy it.

As you develop code in the future using this approach, I think you'll find that if something were to go wrong, it would most likely be a misusing of an external API in untested code. I'd love to have some quicker feedback on that as well, so stay tuned for a future blog post exploring Integration Testing strategies with Firebase.

Evolving Code Reviews Into Pair Programming

James McMahon — Thu, 02 Jan 2020 03:47:11 +0000

Code reviews are becoming more and more standard in the software industry at large. Pair programming, on the other hand, is a rarer practice. These practices are not as disparate as they may initially seem. In fact, I'd argue that pair programming, or pairing for short, is a natural refinement of the practice of code review.

Benefits of Code Review

Let's start by looking at some of the benefits of code reviews, in no particular order:

Higher-quality code
Potential to find alternative solutions
Fewer defects
Shared ownership of the code
Context sharing

There are probably a few I am missing, but that seems like a sound and uncontroversial list.

There is a trick; however, these benefits don't come from just any old code review; they come from well-run code reviews. There are a few pitfalls.

Code Review Problems

I've seen code reviews go wrong in a few different ways:

The amount of context to understand the feature is too high. IE, the author has more context on the problem then the rest of the team, and no one else on the team can give them meaningful feedback.
The "oops" rewrite everything problem. The author did not fully understand the context of the feature under review before they started to write code. IE, another teammate has more context than the author and wasn't able to share context effectively beforehand.

Other things can go wrong, feature branches that never end, the code review turning into a human linting session, but for the most part, these problems stem back to the communication issues listed above.

The precarious part of any code review process is shared context. But wait, wasn't that one of the benefits of code reviews we listed above? Well, the trick is, even if you live in a perfect world and everyone on your team understands every single line of code in your codebase, you still just developed a bunch of new context in your code review. Anyone reviewing that code now needs to climb the mountain to understand what you just wrote. So even in an ideal world, there is some work to build context. That's not the end of the world, we all know reading code is the hard part, but it's well worth the effort for the benefits. Since we can't avoid this overhead, how do we fix the two scenarios above? The answer is feedback, or more specifically, the feedback cycle.

Tightening Up The Process

The trick is to move to a quicker cycle for reviews, taking an approach of "review early, review often." If we want to avoid context gaps and reap benefits at a faster cadence, keep reviews short, and get that code merged in post review.

Flawless plan, right? No, you say? Well, I guess you are right, there are two problems here.

Some features/stories/tasks don't lend themselves to small commits.
Everyone else has work to do. We can't just stop everything to code review all the time.

These problems are opposite sides of the same coin. They both are part of the reality of engineering work that leads to pull requests sitting idle for hours or maybe even days (or maybe even weeks). This leads to even greater context holes, as the original author has moved on to other features and now needs to pay their own context penalty when they context-switch back to the code review they requested.

Evolution

So what's the solution? Well, I gave it away at the beginning, but it really is pair programming. All those benefits I listed for code review above, you get them all. Not only that, but you get those benefits at a much higher cadence. It also solves the two problems with the review early, review often approach.

No one is waiting on any code reviews anymore because your pair is beside you and invested in getting the commit done. If you adhere to a two pizza team you now have a non-trivial percent of your team working on any given commit. If a commit is exceptionally hairy or you are lacking some domain expertise, either start the pair with the engineers you need involved or call them over when the task is done and do the code review in person. I guarantee this does wonders for context sharing, and the need to do a three-person review drops as your team works on the codebase together.

For larger features, you now have the focus on the entire pair. Better yet, if a feature is going to carry over to another day, you have an opportunity to establish a regular cadence of pair rotation. Keep one member of the pair on the feature and rotate another engineer on. At the end of the cycle, the context shared would be higher than any code review I've ever participated in.

Questions About Pairing

Wait, you want two people to do the same job?

Yes, I do. Code reviews are widespread because there is a widespread acceptance of the benefits. What I am saying is that pair programming is just a refined version of code reviews with all the benefits and without several major drawbacks.

But this code is trivial and not worth the time of two engineers

I hear this a bunch when discussion of pair programming comes up. If the code is worth reviewing, it's worth pairing on. If it's not worth reviewing, well, I see a more substantial smell in having a non-trivial amount of "trivial" code in a codebase. That feels like a missing abstraction.

Do I really have to pair all the time?

You don't. There are points were splitting off makes a lot of sense. For instance, if the pair needs to read some documentation, or needs to take some time and experiment with different solutions. In general, you should be paying attention and favoring writing production code with a pair, but there are good reasons to split. The important thing is to make sure you are splitting because it makes sense and not because you are avoiding pairing or (worse) your pair, which brings me to the next point.

Pairing sounds great for other people, but I just don't think that way

So here is something I don't think gets said enough, pairing is hard, especially when you first start. Some come more naturally to it than others, but pairing is a skill. It is a skill that develops over time. You need to be patient with your pair and, more importantly, yourself when you are learning this new skill. Don't be afraid to take breaks. If you are struggling trying switching pairing styles or slowing down and spending extra time externalizing your thoughts. I've been pair programming professionally pretty much every day for about 3 years now, and I still occasionally get movements where I stumble over my words or go silent for a bit while I work out how to best communicate a concept.

If it is that hard, why do it?

Here is the thing, it works. I had a client tell me once, "the code I am writing now is the best code I feel like I've ever written in my career." That client was not a junior, he was a seasoned engineer with a long career, and he walked into pairing with a skeptics mind and got something out of it. Honestly, after reflecting over the last 3 years, I think I agree with him. The code I am writing now feels like the best code I've written. I go back to code I wrote with a pair weeks or months ago, that code just reads better. It's gotten to a point where I wish I could pull someone aside on weekends occasionally to pair on some of my hobby projects.

Wrapping up

So there it is, my case for evolving your code reviews into pair programming. I've only scratched the surface, as there other benefits that come along with an established pair programming practice that go above and beyond the benefits of code review. Hopefully, what I've written is enough to pique your curiosity and convince you to give it a try. After evolving your code reviews practice to pair programming, you'll find you spend less time on the mechanics of code review and more time writing quality code.

DEV Community: James McMahon

TDD success/horror stories? #discuss 🙀

Don't get stuck with out of date dependencies!

For Gradle

Use Latest Versions Plugin

For Node

updtr

Wrap Up

The No-Nonsense Guide to JVM 14 Memory on Kubernetes

MaxRAMPercentage and Kubernetes

If no limit are set on the pod

Limits set on the container

For less than 100% MaxRAMPercentage

For 100% MaxRAMPercentage

What to set as max?

What about requests?

Additional Resources / References

Add Keyboard Shortcuts to your Vue App ⌨️

Implementing

Testing

Sentry with Spring Boot (The Better Way)

TLDR

Environment Variables

The longer explanation

You'll see a scary looking message about Sentry being disabled on boot up.

Errors / Warnings that happen at bootup will not be captured by Sentry.

Wrap Up

Sentry with Spring Boot

Vue Router Testing Strategies

Why

How

What about router-view?

Conclusion

Creating Serverless Functions using TDD

Firebase

Diving In

Problem

Testing Approach

Thinking it through

Controller

Service

Repository

Testing and implementing

Controller

Service

The bits that are harder to test

FileService

Repository and index.ts

Evolving Code Reviews Into Pair Programming

Benefits of Code Review

Code Review Problems

Tightening Up The Process

Evolution

Questions About Pairing

Wrapping up

For less than 100% `MaxRAMPercentage`

For 100% `MaxRAMPercentage`