How to flexibly leverage a simple pipeline template file in your own release pipelines.


Original approach idea credit goes to [Ryan Hatfield](https://github.com/ryanhatfield) who
[helpfully pulled my understanding](https://github.com/microsoft/azure-pipelines-tasks/issues/15936#issuecomment-1042516408)
of pipeline possibilities along. My work here builds on that inspiration.

## Why a template?

Foremost, I need to explain this extra layer of abstraction. It is 100% ok to have the stages in your pipeline
simply repeat steps. It's actually quite easy to do while avoid duplication using
[pipeline variables](https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch)
and [yaml anchors](https://yaml.org/spec/1.2.2/).

We started reaching for templates not knowing about yaml anchors, but I'm glad we did. We now have
over 150 pipelines in the company, and the number is growing fast. Anchors would not solve that problem.
Sharing task definitions between pipelines requires
[templates](https://docs.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops).
Get on board early, and be flexible.

## Template: `templates/helm-upgrade.yaml`

Here's our standard template:

```yaml
parameters:
  # The K8s namespace as passed down from the {Environment.Resource} most often.
  - name: namespace
    type: string
  - name: releaseName
    type: string
  # The location of the chart downloaded to the stage from the artifact
  - name: chartPath
    type: string
    default: $(Pipeline.Workspace)/_Artifact/drop/helm
  # Parameters to pass along to the helm command
  - name: arguments
    type: string
    default: "--create-namespace"
  # This will allow us to pass any helm chart values through as a parameter to helm upgrade template.
  - name: values
    type: object
    default: {}

steps:
  # Convert parameters.values into a local file on the stage operator
  - script: |
      echo '${{ convertToJson(parameters.values) }}' > ./localValues.json
      cat ./localValues.json
    displayName: Create values file
  # I ship it
  - task: HelmDeploy@0
    displayName: "helm upgrade"
    inputs:
      namespace: ${{ parameters.namespace }}
      command: upgrade
      chartType: FilePath
      chartPath: ${{ parameters.chartPath }}
      releaseName: ${{ parameters.releaseName }}
      valueFile: ./localValues.json
      arguments: ${{ parameters.arguments }}
      waitForExecution: false
```

This can be used as a template shared between pipelines in the project, or even externalized to another repository
of pipeline templates you can download on demand.

## Pipeline: `deployment.yaml`

The primary deployment files can then simply include helm values at will:

```yaml
variables:
  vmImage: ubuntu-latest
  releaseName: some-release-name
  # This magic string is a pointer at the service connection shared to the project
  containerRegistryServiceConnection: "CloudProvider - some-project-12345"
  containerRepository: "some-project-12345/some-image"
  containerTag: $(Build.BuildId)

stages:
  # Create and public a container to your registry via whatever means you need
  - stage: Prepare
      displayName: Prepare the base artifact
      jobs:
        - job: Prepare
          pool:
            vmImage: $(vmImage)
          displayName: Prepare job
          steps:
            # Publish our source code.
            # Be sure to have a meaningful `.artifactignore` to manage this.
            - publish: $(System.DefaultWorkingDirectory)
              artifact: drop
            - template: templates/docker-build.yml
              parameters:
                containerRegistryServiceConnection: $(containerRegistryServiceConnection)
                containerRepository: $(containerRepository)
                containerTag: $(containerTag)

  # Any stages you may need for deployment
  - stage: Test
    displayName: Deploy to the Test environment
    variables:
      hostName: test.{hostName}
      containerTag: $(resources.pipeline._Artifact.runID)
    jobs:
      - deployment: Deploy
        pool:
          vmImage: $(vmImage)
        environment: Environment.Resource
        strategy:
          runOnce:
            deploy:
              steps:
                # While we publish the entire artifact for visibility,
                # we really only need the helm chart to upgrade.
                - download: current
                  artifact: drop
                  patterns: |
                    helm/**/*.*
                # Use our template with any customized values we require.
                - template: templates/helm-upgrade.yml
                  parameters:
                    namespace: $(Environment.ResourceName)
                    releaseName: $(releaseName)
                    #  arguments: --dry-run --debug
                    values:
                      image:
                        tag: $(containerTag)
                      ingress:
                        hosts:
                          - host: $(hostName)
                            paths:
                              path: /
                              pathType: ImplementationSpecific
                        tls:
                          - secretName: $(hostName)-tls
                            hosts:
                              - $(hostName)
```

## Reviewing the output

The "Create values file" will output your values into a local json file
and also include the results in your step for review:

```json
{
  "image": {
    "tag": "1234"
  },
  "ingress": {
    "hosts": [
      {
        "host": "test.{hostname}",
        "paths": [
          {
            "path": "/",
            "pathType": "ImplementationSpecific"
          }
        ]
      }
    ],
    "tls": [
      {
        "secretName": "test.{hostname}-tls",
        "hosts": ["test.{hostname}"]
      }
    ]
  }
}
```

Good luck to you, and happy helm piping!


Using environment specific values in Azure DevOps Helm task

Running a secure Kubernetes cluster means knowing what to lock down, here's the details for CertManger.


It's been a grueling, slightly inebriated, 12 hours.
We (read: Java and Typescript developers) had a plan for getting Kubernetes running.
Public clusters, wide open, [CertManager](https://cert-manager.io/) and
[Nginx Ingress](https://kubernetes.github.io/ingress-nginx/) controllers. Then our
_real_ DevOps team got involved and pointed out the very important flaw in our plan,
security.

That's the thing. All the best laid plans and 'OMG. I got it working!' from newbies (read: me)
should be met with cheers. Kubernetes is hard. Harder and _more important_, is getting security
right. I owe thanks [Mark Kalusha](linkedin.com/in/mark-kalusha-9681a13) and
[Greg Lettow](linkedin.com/in/greglettow) for working with me on this.

Do the right thing, help your fellow DevOps teams out. Secure your cluster.

## Error messages

You may be facing this problem in your own cluster if you're seeing any of the following errors:

- Error: UPGRADE FAILED: failed to create resource: Internal error occurred:
  failed calling webhook "validate.nginx.ingress.kubernetes.io":
  Post "https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1/ingresses?timeout=10s":
  context deadline exceeded
- Error: UPGRADE FAILED: failed to create resource: Internal error occurred:
  failed calling webhook "validate.nginx.ingress.kubernetes.io":
  Post "https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1/ingresses?timeout=10s":
  dial tcp 10.0.21.149:8443: i/o timeout
- Reason: Waiting for HTTP-01 challenge propagation:
  failed to perform self check GET request
  'http://test.*.torch.ai/.well-known/acme-challenge/LtQsipkH5PE4p6NiT0lfur-7ljl4tLEHA9zpWEg6iv4':
  Get "http://test.*.torch.ai/.well-known/acme-challenge/LtQsipkH5PE4p6NiT0lfur-7ljl4tLEHA9zpWEg6iv4":
  context deadline exceeded (Client.Timeout exceeded while awaiting headers), Processing: true, Presented: true
- Waiting for HTTP-01 challenge propagation:
  failed to perform self check GET request
  'http://test.*.torch.ai/.well-known/acme-challenge/LtQsipkH5PE4p6NiT0lfur-7ljl4tLEHA9zpWEg6iv4':
  Get "http://test.*.torch.ai/.well-known/acme-challenge/LtQsipkH5PE4p6NiT0lfur-7ljl4tLEHA9zpWEg6iv4":
  dial tcp 18.217.101.253:80: i/o timeout (Client.Timeout exceeded while awaiting headers), Processing: true, Presented: true
- State: invalid, Reason: Error accepting authorization: acme:
  authorization error for test.\*.torch.ai: 400 urn:ietf:params:acme:error:dns:
  DNS problem: SERVFAIL looking up CAA for torch.ai
  the domain's nameservers may be malfunctioning, Processing: true, Presented: true

## Ports required

You'll need to these ports added to your own security groups:

### Ingress

- 80 - acme solver
- 443 - Standard communications
- 8443 - Nginx Ingress service internal lookups
- 9443 - K8s Ingress webhook
- 8089 - acme solver

### Egress

- 80 - egress solver
- 443 - egress communications


A gold mine of ports extracted from undocumented error hell

Kubernetes - Required ports for CertManager and Nginx Ingress controller

An improved cross project dashboard for understanding your assigned work with context.


I've worked with [Azure DevOps](https://azure.microsoft.com/en-us/services/devops/) in two companies
now. In both cases, it's always been a constant struggle to decide if you should have one project,
with multiple teams that have their own sprints and areas or multiple projects. It's hard to say
what is "right." The standard "it depends" applies based on things like sensitive context,
external team members, and organizational access. Both of my previous companies choose to go with
multiple projects. Once started, it's a decision that _quickly_ becomes unwieldy unless to use
the stock tools.

## Default - "My work items"

One of the worst offending tools, perhaps even if you choose only a single project is
["My work items"](https://dev.azure.com/TorchResearchLLC/_work). There's a slightly stronger
version suggested in their
[working across projects](https://docs.microsoft.com/en-us/azure/devops/project/navigation/work-across-projects?view=azure-devops)
documentation. Neither provides you enough context to understand the work.

A good view of your dashboard needs to identify:

- The project ✅
- The iteration or sprint
- The id ✅
- The type ✅
- The title ✅
- The status ✅
- The parent item
- The priority

Bonus points for:

- The remaining work (in hours)
- Collapsible hierarchy to hide what you don't need
- A method to open as a [query](https://docs.microsoft.com/en-us/azure/devops/boards/queries/view-run-query?view=azure-devops&tabs=browser)
  for full functionality.
- Sorting control

### Score: 5/12

It's not that I refuse use it, but there surely is better.

## Custom - "My work items" Dashboard

Enter our new beauty, a collection of widgets driven by queries:

![A dashboard with original estimates, completed work, type breakdown, and remaining items with context.](/posts/2022/azure-devops-work-items-dashboard.jpg)

For sheer joy, let's run the numbers:

- The project ✅
- The iteration or sprint ✅
- The id ✅
- The type ✅
- The title ✅
- The status ✅
- The parent item ✅
- The priority ✅

Bonus points for:

- The remaining work (in hours) ✅
- Collapsible hierarchy to hide what you don't need ✅
- A method to open as a [query](https://docs.microsoft.com/en-us/azure/devops/boards/queries/view-run-query?view=azure-devops&tabs=browser)
  for full functionality. ✅
- Sorting control ✅

### Score: 12/12

Let's break down how it was built in parts. The key is the use of
[queries](https://docs.microsoft.com/en-us/azure/devops/boards/queries/view-run-query?view=azure-devops&tabs=browser)
set for cross project access. We'll define two:

### My completed work

Query across projects: `[X]`  
Type of query: `Flat list of work items`  
Work Item Type: `=` `Task`  
`And` State: `<>` `Closed`  
`And` State: `<>` `Done`  
`And` Closed Date: `>=` `@StartOfDay('-90d')`  
`And` Assigned To: `=` `@Me`

Column options:

Fields:

- Id (purely for reference)
- Title (purely for reference)
- Assigned To
- Original Estimate
- Completed Work
- Activity

This query will be for the three pie charts at the top of the dashboard. You can add
three [Charts for work items](https://docs.microsoft.com/en-us/azure/devops/report/dashboards/widget-catalog?view=azure-devops#chart-wit-widget)
to aggregate the query items to help your team understand their estimated vs actual hours and work types.

### My open work

Query across projects: `[X]`  
Type of query: `Tree of work items`

Filters for level work items:  
Work Item Type: `=` `User Story` `Or` Work Item Type: `=` `Bug`  
`And` State: `<>` `Closed`

Filters for linked work items:  
Work Item Type: `=` `Task`  
`And` State: `<>` `Closed`  
`And` State: `<>` `Done`  
`And` Assigned To: `=` `@Me`

Column options:

Fields:

- Iteration Path
- Id
- Title
- State
- Priority
- Assigned To
- Story Points
- Original Estimate
- Remaining Work
- Completed Work
- Activity

Sorting:

- Priority ascending
- Iteration Path ascending
- Remaining Work ascending

This query will be used to pull items into a
[query result](https://docs.microsoft.com/en-us/azure/devops/report/dashboards/widget-catalog?view=azure-devops#query-results-widget)
which will elect to omit some of the fields for brevity. Users in need of more context or
mass editing can use the link to view the additional columns you define that help customize
the context required for your company.

Hopefully this makes it easier to understand what, why, and in what order you need to take on.
If anyone happens to know a means of adding your capacity from a project, I'd love to see that added.

Happy building, and cheers!


A dashboard replacement to keep your team in the know.

Azure DevOps - My work items

Provides a guide to using your own themes semantic colors with AMChart's interface properties.


I've been working with [AMCharts](https://www.amcharts.com/) for almost 2 years.
The tooling for it is Typescript heaven, and they earned my money on just that
at first. The support seen pretty decent support on GitHub, and better if
licensed. They do have their own [themes](https://www.amcharts.com/docs/v5/concepts/themes/)
including a [Material](https://material.io/design) version.

Of course, someone else's work is never quite your own use case. Naturally we started looking
to dynamically create an AMCharts theme based on our Material UI (4.x) theme. The 4.x
was done a couple of years ago. Our 5.x came with a few changes just this week.
I thought I'd post both in case you need to do the same.

## AMCharts 4.x

The 4.x branch used returned functions that could be run. We use
`getMaterialSemanticsTheme` to return our theming standards:

```ts
import { Theme as MaterialTheme } from "@material-ui/core";
import { ITheme as AMChartsTheme } from "@amcharts/amcharts4/.internal/themes/ITheme";

type GetAMChartsThemeFromMaterialTheme = (
  theme: MaterialTheme
) => AMChartsTheme;
const getMaterialSemanticsTheme: GetAMChartsThemeFromMaterialTheme = (
  theme
) => {
  return (target) => {
    if (target instanceof InterfaceColorSet) {
      // target.setFor("stroke", color(theme.palette.background.default));
      // target.setFor("fill", color(theme.palette.text.primary));
      target.setFor("primaryButton", color(theme.palette.primary.main));
      target.setFor("primaryButtonHover", color(theme.palette.primary.light));
      target.setFor("primaryButtonDown", color(theme.palette.primary.dark));
      target.setFor("primaryButtonActive", color(theme.palette.primary.dark));
      target.setFor(
        "primaryButtonText",
        color(theme.palette.primary.contrastText)
      );
      target.setFor("primaryButtonStroke", color(theme.palette.divider));
      target.setFor("secondaryButton", color(theme.palette.secondary.main));
      target.setFor(
        "secondaryButtonHover",
        color(theme.palette.secondary.light)
      );
      target.setFor("secondaryButtonDown", color(theme.palette.secondary.dark));
      target.setFor(
        "secondaryButtonActive",
        color(theme.palette.secondary.dark)
      );
      target.setFor(
        "secondaryButtonText",
        color(theme.palette.secondary.contrastText)
      );
      target.setFor("secondaryButtonStroke", color(theme.palette.divider));
      target.setFor("grid", color(theme.palette.text.secondary));
      target.setFor("background", color(theme.palette.background.default));
      // target.setFor("alternativeBackground", color(theme.palette.text.primary));
      target.setFor("text", color(theme.palette.text.primary));
      // target.setFor("alternativeText", color(theme.palette.background.paper));
      target.setFor(
        "disabledBackground",
        color(theme.palette.action.disabledBackground)
      );
      target.setFor("positive", color(theme.palette.success.main));
      target.setFor("negative", color(theme.palette.error.main));
    }

    if (target instanceof AxisRenderer) {
      target.labels.template.fill = color(theme.palette.text.secondary);
    }
  };
};
```

### Usage of `getMaterialSemanticsTheme`

The below is a stripped down example. We used a `React.Context` provider in the past
as the theme elements from AMCharts were applied to all graphs.

```tsx
import React, { useEffect, useState } from "react";
import { useTheme as useMaterialUITheme } from "@material-ui/core";
import {
  useTheme,
  unuseAllThemes,
  addLicense,
  InterfaceColorSet,
  color,
} from "@amcharts/amcharts4/core";

export const Provider: React.FunctionComponent<ChartsContextProviderProps> = ({
  children,
}) => {
  const theme = useMaterialUITheme();

  useEffect(() => {
    // Clear the existing themes on theme change
    unuseAllThemes();

    if (theme.palette.type === "dark") {
      useTheme(am4themes_dark);
    }

    // Apply the elements of Material UI interface to the charts
    useTheme(getMaterialSemanticsTheme(theme));
    setCurrentTheme(theme);
  }, [useAnimations, theme]);

  return (
    <ChartsContextProvider.Provider value={{}}>
      {children}
    </ChartsContextProvider.Provider>
  );
};
```

## AMCharts 5.x

In 5.x they've made great improvements in performance. Part of that involves a
new statically created root, removing many of the global elements. Working with
it has been greatly rewarding, and worth any headache it takes rewriting
to gain encapsulation and performance.

Themes mechanism have changed from a returned function to an instantiation
of a `Theme` like all of their
[static constructors](https://www.amcharts.com/docs/v5/getting-started/root-element/#Using).
The standard `Theme.new()` call doesn't take any arguments, but it's easy enough to
extend it with your own class, protected variable, and static method:

`SemanticTheme.ts`

```ts
import { Theme as AMChartsTheme } from "@amcharts/amcharts5/.internal/core/Theme";
import { Theme as MaterialTheme } from "@material-ui/core/styles/createTheme";
import { color, Root } from "@amcharts/amcharts5";

export class SemanticTheme extends AMChartsTheme {
  protected materialTheme: MaterialTheme | undefined = undefined;

  // This is basically a copy of what new() does
  static newFromMaterialTheme(root: Root, materialTheme: MaterialTheme) {
    const x = new this(root, true);
    // With one little addition
    x.materialTheme = materialTheme;
    x.setupDefaultRules();
    return x;
  }

  setupDefaultRules() {
    const theme = this.materialTheme;
    if (!theme) {
      throw new Error("this.materialTheme is undefined");
    }

    // Note that these will work non-cooperatively with Dark:
    this.rule("InterfaceColors").setAll({
      // node_modules/@amcharts/amcharts5/.internal/themes/DarkTheme.js
      // stroke: color(0x000000),
      // fill: color(0x2b2b2b),
      // primaryButton: Color.lighten(Color.fromHex(0x6794dc), -0.2),
      // primaryButtonHover: Color.lighten(Color.fromHex(0x6771dc), -0.2),
      // primaryButtonDown: Color.lighten(Color.fromHex(0x68dc75), -0.2),
      // primaryButtonActive: Color.lighten(Color.fromHex(0x68dc76), -0.2),
      // primaryButtonText: color(0xffffff),
      // primaryButtonStroke: Color.lighten(Color.fromHex(0x6794dc), -0.2),
      // secondaryButton: color(0x3b3b3b),
      // secondaryButtonHover: Color.lighten(Color.fromHex(0x3b3b3b), 0.1),
      // secondaryButtonDown: Color.lighten(Color.fromHex(0x3b3b3b), 0.15),
      // secondaryButtonActive: Color.lighten(Color.fromHex(0x3b3b3b), 0.2),
      // secondaryButtonText: color(0xbbbbbb),
      // secondaryButtonStroke: Color.lighten(Color.fromHex(0x3b3b3b), -0.2),
      // grid: color(0xbbbbbb),
      // background: color(0x000000),
      // alternativeBackground: color(0xffffff),
      // text: color(0xffffff),
      // alternativeText: color(0x000000),
      // disabled: color(0xadadad),
      // positive: color(0x50b300),
      // negative: color(0xb30000),

      // Material implementation
      // stroke: color(theme.palette.background.default), // I'm still debating this one
      // fill: color(theme.palette.text.primary), // I'm still debating this one
      primaryButton: color(theme.palette.primary.main),
      primaryButtonHover: color(theme.palette.primary.light),
      primaryButtonDown: color(theme.palette.primary.dark),
      primaryButtonActive: color(theme.palette.primary.dark),
      primaryButtonText: color(theme.palette.primary.contrastText),
      primaryButtonStroke: color(theme.palette.primary.main),
      secondaryButton: color(theme.palette.secondary.main),
      secondaryButtonHover: color(theme.palette.secondary.light),
      secondaryButtonDown: color(theme.palette.secondary.dark),
      secondaryButtonActive: color(theme.palette.secondary.dark),
      secondaryButtonText: color(theme.palette.secondary.contrastText),
      secondaryButtonStroke: color(theme.palette.secondary.light),
      grid: color(theme.palette.text.secondary),
      background: color(theme.palette.background.default),
      alternativeBackground: color(theme.palette.text.primary),
      text: color(theme.palette.text.primary),
      alternativeText: color(theme.palette.background.paper),
      disabled: color(theme.palette.action.disabled),
      positive: color(theme.palette.success.main),
      negative: color(theme.palette.error.main),
    });

    this.rule("AxisRenderer").setAll({
      fill: color(theme.palette.text.secondary),
    });
  }
}
```

### Usage of `SemanticTheme.ts`

The new root requirement makes this a lot easier to understand.
You make a root, you use some themes on it immediately. If your
theme changes, dispose the old one, and create a new root.

To chart theming standard, we created some root helper functions:

```ts
import { Root } from "@amcharts/amcharts5";
import am5themes_dark from "@amcharts/amcharts5/themes/Dark";
import am5themes_Animated from "@amcharts/amcharts5/themes/Animated";
import am5themes_Responsive from "@amcharts/amcharts5/themes/Responsive";
import am5themes_Micro from "@amcharts/amcharts5/themes/Micro";
import { Theme as AMChartsTheme } from "@amcharts/amcharts5/.internal/core/Theme";
import { Theme as MaterialTheme } from "@material-ui/core/styles";
import { SemanticTheme } from "../themes/SemanticTheme";

type NewRoot = (
  /** The id of a container or an HTMLDivElement */
  container: string | HTMLDivElement,
  settings?: RootSettings
) => Root;

export interface RootSettings {
  /** Provides direct control over animations. If not provided the user's window preference will be used */
  useAnimations?: boolean;
  /** Provides direct control over animations. Default: true */
  useResponsive?: boolean;
  /** Enables the Micro theme -  charts stripped down to a bare minimum (no labels, axes, etc.). Suitable creating charts with very minimal space requirements. */
  useMicro?: boolean;
  materialTheme?: MaterialTheme;
}

/**
 * Returns a root with all of standard properties applied.
 *
 * If not directly specified, and window preferences are available
 * they will be used for determining animation and dark theme support.
 */
export const newRoot: NewRoot = (container, settings = {}) => {
  const root = Root.new(container);

  const themes = getThemes(root, settings);
  root.setThemes(themes);

  return root;
};

type GetThemes = (root: Root, settings: RootSettings) => AMChartsTheme[];
const getThemes: GetThemes = (root, settings) => {
  // Themes
  const themes: AMChartsTheme[] = [];

  // Animations
  let useAnimations: boolean;
  if (typeof settings.useAnimations === "boolean") {
    useAnimations = settings.useAnimations;
  } else {
    useAnimations =
      window && window.matchMedia("(prefers-reduced-motion: reduce)").matches;
  }
  if (useAnimations) {
    themes.push(am5themes_Animated.new(root));
  }

  // Responsive
  const useResponsive: boolean =
    typeof settings.useResponsive === "boolean" ? settings.useResponsive : true;
  if (useResponsive) {
    themes.push(am5themes_Responsive.new(root));
  }

  if (settings.useMicro) {
    themes.push(am5themes_Micro.new(root));
  }

  getThemesFromMaterialTheme(root, settings.materialTheme).forEach((theme) => {
    themes.push(theme);
  });

  return themes;
};

const getThemesFromMaterialTheme = (
  root: Root,
  materialTheme?: MaterialTheme
): AMChartsTheme[] => {
  const themes: AMChartsTheme[] = [];

  // If we weren't given a specific theme
  if (!materialTheme) {
    // At least respect the user's color scheme
    if (window && window.matchMedia("(prefers-color-scheme: dark)").matches) {
      themes.push(am5themes_dark.new(root));
    }

    // TODO maybe respect their contrast preferences?
    return themes;
  }

  if (materialTheme.palette.type === "dark") {
    themes.push(am5themes_dark.new(root));
  }

  const semanticTheme = SemanticTheme.newFromMaterialTheme(root, materialTheme);
  themes.push(semanticTheme);

  return themes;
};
```

This makes creating theme dependent chart a breeze. Based on their own
docs, we end up with a function component like this:

```tsx
import React, { useRef, useLayoutEffect } from "react";
import { useTheme } from "@material-ui/core";

export const ExampleChart: React.FunctionComponent = () => {
  const theme = useTheme();
  const element = useRef<HTMLDivElement | null>(null);

  useLayoutEffect(() => {
    if (!element.current) {
      throw new Error("element.current is not defined");
    }

    const root = newRoot(element.current, { materialTheme: theme });

    // Your own chart logic

    return () => root.dispose();
  }, [theme]);

  return <div ref={element} />;
};
export default ExampleChart;
```

### Working with more complex AMCharts, data, timing, and reuse

The example here provides _very_ over simplified usage. Trying to
create a reusable component out of the `React.FunctionComponent` above
would quickly become a snarl of callback props and race conditions. I
do _not_ suggest this approach more than a single usage. I'm investigating
standardizing work into Context that house the `root` and standardize as
much as we can, with smart children that can manage specifics and data
this week. Hopefully that will become its own post in the coming weeks.

Looking forward to seeing you back!

Cheers


Creating dynamic AMCharts 5 themes from Material UI themes

A guide to packages, setup, resolvers, utilities, and integration testing of file uploads.


Getting file uploads into our stack has been a joy. I wanted to break
down our approach in the hopes it saves someone a bit of heartache.
Here's the tools we'll be using:

- [Apollo server](https://www.apollographql.com/docs/apollo-server/)
  through [middleware](https://www.apollographql.com/docs/apollo-server/integrations/middleware/).
  - [graphql-upload](https://www.npmjs.com/package/graphql-upload)
- [Jest](https://jestjs.io/)
  - [supertest](https://www.npmjs.com/package/supertest)

For the full example of my GraphQL server setup, see the
[example project](https://github.com/lancegliser/node-express-apollo-graphql) on GitHub.

## GraphQL

I'll omit a great deal as the focus is only on upload. Your mechanism should
define its own file and ids handling. My own is based on
[ArangoDB](https://www.arangodb.com/), but that's outside this article's scope.

In this example I've removed my typical GraphQL namespacing that allows
queries and mutations as example below would show. Someday I'll get around to
an entry on that...

```graphql
mutation AddFile($file: Upload!) {
  file {
    add(file: $file) {
      _key
      displayName
    }
  }
}
```

For a basic upload, we're looking at something similar to this:

```graphql
scalar Upload
type Mutation

extend type Mutation {
  "Uploads a file to a cloud provider and returns file object"
  addFile(file: Upload!): File
}

type File implements IDocument & ICreated & IDisplayName {
  "Unique identifier for the resource across all collections"
  _id: ID
  "Unique identifier for the resource within its collection"
  _key: ID
  "Unique identifier for revision"
  _rev: String
  "ISO date time string for the time this resource was created"
  createdAt: String
  "Unique identifier for user that created this resource"
  createdBy: ID
  "The original preformatted name safe to display in any HTML context"
  displayName: String
  "A renderedable source safe to display in HTML context"
  displayImageUrl: String
  "The public url of the file"
  publicUrl: String
  "The storage provider for this file"
  storageProvider: CloudProvider
  "The storage location or file path to this file"
  bucket: String
  "The actual file name as used in storage"
  fileName: String
  "The file size in bytes"
  size: Int
  mimetype: String
  encoding: String
}

enum CloudProvider {
  GoogleCloudPlatform
  AmazonWebServices
}

interface IDocument {
  "Unique identifier for the resource across all collections"
  _id: ID
  "Unique identifier for the resource within its collection"
  _key: ID
  "Unique identifier for revision"
  _rev: String
}

interface ICreated {
  "ISO date time string for the time this resource was created"
  createdAt: String
  "Unique identifier for users that created this resource"
  createdBy: ID
}

interface IDisplayName {
  "A preformatted display name safe to display in HTML context"
  displayName: String
}
```

## Resolvers

I typically split my code into logical components. At the top level I use
an index file like this to gather all the resolvers and graphql schemas.

### `src/components/index.ts`

```ts
import { GraphQLFileLoader } from "@graphql-tools/graphql-file-loader";
import { loadSchema } from "@graphql-tools/load";
import { IResolvers } from "@graphql-tools/utils/Interfaces";
import { GraphQLSchema } from "graphql";
import { addResolversToSchema } from "@graphql-tools/schema";
import { addResolvers as addFileResolvers } from "./files/files.resolvers";
import { GraphQLUpload } from "graphql-upload";

export const getSchemaWithResolvers = async (): Promise<GraphQLSchema> => {
  // Create a schema based on all `.graphql` files in src/components
  const schema = await loadSchema("./src/**/*.graphql", {
    // load from multiple files using glob
    loaders: [new GraphQLFileLoader()],
  });
  // Prepare resolvers by adding any static packages like Upload or JSON
  const resolvers: IResolvers = {
    Query: {},
    Mutation: {},
    Upload: GraphQLUpload!,
  };

  // Augment the static resolvers with any component resolvers we've written
  addFileResolvers(resolvers);
  // Return the whole package back to the application layer so Apollo can run
  return addResolversToSchema({
    schema,
    resolvers,
  });
};
```

### `src/components/files/files.resolvers.ts`

The component resolvers can then focus on adding just their own logic,
extending the `Query` and `Mutation` objects as required. I use the
same logic for field specific resolvers as you can see commented out.

```ts
import {
  FileResolvers,
  MutationResolvers,
  Resolvers,
} from "../../generated/types";
import { addFile } from "./files.utils";

export const addResolvers = (resolvers: Resolvers): Resolvers => {
  // resolvers.Query = { ...resolvers.Query, ...query };
  resolvers.Mutation = { ...resolvers.Mutation, ...mutation };
  // resolvers.File = fileResolvers;
  return resolvers;
};

const mutation: MutationResolvers = {
  addFile: (parent, args, context) => addFile(args, context),
};

// const fileResolvers: FileResolvers = {
//   publicUrl: (parent, args, context) => {
//     if(parent.publicUrl){
//       return parent.publicUrl;
//     }
//     // TODO if requested, make the file public and return the url
//   }
// }
```

#### Where did `MutationResolvers` come from?

The autocomplete types generated by GraphQL codegen are just
so tasty it's unbelievable. Implementation time and error
counts dropped significantly once we started using them.
Huge thanks to: [The Guild's code generator](https://www.graphql-code-generator.com/). 🚀

To say "it's complicated" would be an understatement. Here's a sample of what gets
generated:

```ts
// ContextType is my own definiton passed through to the generator
export type MutationResolvers<
  ContextType = GraphQLContext,
  ParentType extends ResolversParentTypes["Mutation"] = ResolversParentTypes["Mutation"]
> = {
  /** Uploads a file to a cloud provider and returns file object */
  addFile?: Resolver<
    Maybe<ResolversTypes["File"]>,
    ParentType,
    ContextType,
    RequireFields<MutationsAddFileArgs, "file">
  >;
};

export type ResolverTypeWrapper<T> = Promise<T> | T;

export type File = ICreated &
  IDisplayName &
  IDocument & {
    __typename?: "File";
    /** Unique identifier for the resource across all collections */
    _id?: Maybe<Scalars["ID"]>;
    /** Unique identifier for the resource within its collection */
    _key?: Maybe<Scalars["ID"]>;
    /** Unique identifier for revision */
    _rev?: Maybe<Scalars["String"]>;
    /** The storage location or file path to this file */
    bucket?: Maybe<Scalars["String"]>;
    /** ISO date time string for the time this resource was created */
    createdAt?: Maybe<Scalars["String"]>;
    /** Unique identifier for user that created this resource */
    createdBy?: Maybe<Scalars["ID"]>;
    /** A renderedable source safe to display in HTML context */
    displayImageUrl?: Maybe<Scalars["String"]>;
    // ...
  };
```

The upshot of all their generated work is perfectly translated
GraphQL objects (with interfaces!) _and_ static types for your resolvers.
Many of my resolvers are written take advantage of all that typing:

```ts
const fileResolvers: FileResolvers = {
  someField: ({ id: fileId }, { limit, offset, ...args }, { user }) => {
    // ... some implementation
  },
};
```

If you're not salivating yet, I'll throw one more treat on the pile.
We use the _same_ code generation in our
[React app](https://github.com/lancegliser/react-apollo)
side generating our queries and mutations to get automatic state
management and typings:

```ts
const [addFile, { loading, error, data }] = useAddFileMutation({});
const onClick = async () => {
  await addFile({
    variables: {
      file: null, // your state variable
    },
  });
};
```

## Utilities

Apollo server will have handled most of the requirements up to now
based on just the GraphQL spec and resolvers we added. Custom bits happen in
our utilities. Your own file storage needs are going to be different. I'll
show just the basics of getting where you could store and a return here.

### `src/components/files/files.utils.ts`

```ts
import { ApolloError } from "apollo-server-express";
import { GraphQLContext } from "../context";
import fs from "fs";
import path from "path";
import {
  CloudProvider,
  File,
  MutationsAddFileArgs,
} from "../../generated/types";

const defaultProvider: CloudProvider = CloudProvider.Aws;
const bucket = "uploads";

export const addFile = async (
  // { file: Upload } as defined by graphql-upload
  args: MutationsAddFileArgs,
  // Logging, repositories, and user details
  context: GraphQLContext
): Promise<File> => {
  // Wait for the capacitor upload to complete
  const file = await args.file;

  // When a file is uploaded to the API, the extension is .tmp.
  // Before we can move the file along we need restore the previous name.
  const sourcePathComponents: string[] = file.capacitor._path
    .split(path.sep)
    .slice(0, -1);
  const targetPath = [...sourcePathComponents, file.filename].join(path.sep);
  fs.renameSync(file.capacitor._path, targetPath);

  // TODO your own storage logic on the file at targetPath

  return {
    bucket,
    displayName: file.filename,
    encoding: file.encoding,
    fileName: file.filename,
    mimetype: file.mimetype,
    size: file.capacitor.size,
    storageProvider: provider,
  };
};
```

## Testing

This example will draw slightly on my previous entry about using
[context functions](https://fragmentedthought.com/blog/2021/using-layered-context-functions-to-share-objects-for-jest-integration-testing#context-functions)
to share state between tests.

I've offloaded much of the `describe` and `it` logic, as we're only interested
in how to take a static file and use `supertest` to run an integration test
from all the way outside the app through the resolvers, db, and back.

### `src/components/files/files.test.ts`

```ts
import path from "path";
import { print } from "graphql";
import { gql } from "apollo-server-express";
import supertest from "supertest";
import { File, MutationsAddFileArgs } from "../../generated/types";

describe("files", () => {
  describe("resolvers", () => {
    it("should add file", async () => {
      await withFileContext(async ({ file }) => {
        expect(file.storageProvider).toBeTruthy();
        expect(file.bucket).toBeTruthy();
        expect(file.fileName).toBeTruthy();
      });
    });
  });
});

const fileName = "static.text";
const filePath = path.resolve(`./tests/${fileName}`);

let file: File | undefined;
type TWithFileContext = (
  context: ResolverContext & {
    file: File;
  }
) => Promise<void>;
const withFileContext = async (fn: TWithFileContext) => {
  await withResolverContext(async (context) => {
    if (!file) {
      // In this case the "file" needs a full path to upload
      file = await resolverCreateFile(context, { file: filePath });
      expect(file.fileName).toBe(fileName);
    }

    await fn({ ...context, file });
  });
};

export const resolverCreateFile = async (
  // Application, authentication token
  context: ResolverContext,
  variables: MutationsAddFileArgs
): Promise<File> => {
  // Use `gql` to create an AST tree your IDE can validate against your schemas
  // Then use `print` to change that schema into the required query string
  const query = print(gql`
    mutation AddFile($file: Upload!) {
      addFile(file: $file) {
        _id
        displayName
        storageProvider
        bucket
        fileName
      }
    }
  `);

  // We need to produce a multi-part request that's distinct from the standard graphql request.
  // It looks like the below. the -------#### are form post generated boundaries
  // The "operations" field defines the things we'll be running
  // The "map" defines what to substitute in during execution

  // Start a request, we're going to need to attach to it
  const request = supertest(context.application)
    .post(GRAPHQL_URI)
    .set("authorization", context.authorization)
    // Goal: {"operationName":"AddFile","variables":{"file":null},"query":"mutation AddFile($file: ....
    .field(
      "operations",
      JSON.stringify({
        operationName: "AddFile",
        variables: { file: null }, // This null value is substituted below
        query,
      })
    )
    // Goal: {"1":["variables.file"]}
    .field(
      "map",
      JSON.stringify({
        1: Object.keys(variables).map((key) => `variables.${key}`),
      })
    );

  // Attach the files and fields
  Object.values(variables).forEach((value, i) => {
    if (contentType(path.extname(value))) {
      request.attach(`${i + 1}`, value);
    } else {
      request.field(`${i + 1}`, value);
    }
  });

  // Send the request
  const response = await request;
  expectGraphQLSuccessResponse(response);

  return response.body.data.ontologies.addFile;
};
```

Hopefully this helps someone out there. If you liked it or have a question, please send me a
[tweet](https://twitter.com/intent/tweet?text=%40lancegliser).


GraphQL file upload mutations


A habit I developed a while back was learning to clean up after myself. Deal with
a legacy database that you can't just blow away and you'll come to realize how important
that is. We can, and _should_ [mock](https://jestjs.io/docs/mock-functions) away some of
those concerns when dealing with external systems. When unit testing, there is often
nothing to clean up anyway, or it's simple.

The technique I'll show here today is not for those use cases. It's designed
to help you with a full CRUD cycle through API graphql query and mutation, resolvers,
utils, and eventual database. Real data gets created, updated, processed, and removed.
Yes, I know that might violate some imagined laws of testing. Guess what,
it works really, really well. When working with Proof of Concept ideas,
a full suite of unit tests is overkill. Write one once a bug is identified,
or the logic can't be factored under reasonable
[cyclomatic complexity](https://en.wikipedia.org/wiki/Cyclomatic_complexity)
limits. Unit tests work, but they say nothing about if the system
is working on the whole.

Let's get to it.

## Overview

Today's tests will be written in [Jest](https://jestjs.io/). The
layering of context functions would apply as well in many other tools. Jest
will be able to run through `npm test`, or your own built in IDE controls
with full debugger breakpoint control. Our API will be an
[`apollo-server-express`](https://www.apollographql.com/docs/apollo-server/integrations/middleware/#apollo-server-express)
running GraphQL. We'll hand waive authorization, as that will be specific
to your implementation.

Today's task will be about manipulating an abstract `Group` that can take
generic `GroupMember` (not even users, just objects).

### `groups.graphql`

For specific details of what we'll be testing, you're welcome to review
the schema:

```graphql
extend type Query {
  "Returns all groups available to this users"
  groups: [Group!]!
  group(id: ID!): Group!
}

extend type Mutation {
  saveGroup(group: GroupInput!): Group!
  deleteGroup(id: ID!): Group
  "Adds a member to a group, based on the target selection, and returns the membership and a structure edge if created"
  addMemberToGroup(memberId: ID!, groupId: ID!): [GroupEdge!]!
  "Removes a member from a group, based on the target selection, and returns edges removed"
  removeMemberFromGroup(memberId: ID!, groupId: ID!): [GroupEdge!]!
}

type Group {
  "Unique identifier for the resource across all collections"
  id: ID
  "A preformatted display name safe to display in HTML context"
  displayName: String!
  "ISO date time String for the time this resource was created"
  createdAt: String
  "Unique identifier for users that created this resource"
  createdBy: ID
  "ISO date time String for the time this resource was created"
  updatedAt: String
  "Unique identifier for users that created this resource"
  updatedBy: ID
  "Short description"
  description: String
  "The documents that are a part of the group"
  members: [GroupMember!]
}

input GroupInput {
  "Unique identifier for the resource within its collection"
  id: ID
  "A preformatted name safe to display in any HTML context"
  displayName: String!
  "Short description"
  description: String
}

"A common set of interfaces implemented by all members allowing generic handling"
type GroupMember {
  "Unique identifier for the resource across all collections"
  id: ID
  "A preformatted display name safe to display in HTML context"
  displayName: String!
  "ISO date time String for the time this resource was created"
  createdAt: String
  "Unique identifier for users that created this resource"
  createdBy: ID
  "ISO date time String for the time this resource was created"
  updatedAt: String
  "Unique identifier for users that created this resource"
  updatedBy: ID
}
```

## Integration testing

For those not familiar with Jest, Mocha, Chai, Cypress, the syntax is simple enough:

```ts
// Create an arbitraty group of tests relating to some concept
describe("groups", () => {
  // Logic you can run before our tests in this group
  beforeAll(() => {});

  // Prepare a specific piece of fucntionality you want to know is working
  it("should create a group", async () => {
    // Implement creation and expectation logic
  });

  // Logic you can run after our tests in this group
  beforeAll(() => {});
});
```

### Context functions

I use context functions as a means of organizing code. You could do much
of this inline, using `beforeAll`, but it gets complicated as tests
require additional specifics for operations. Using context functions
allow you separate test specific requirements from `describe` group
concerns.

The goal will become to write tests that look like this. We eliminate
the `beforeAll` setup requirements, and pull just the pieces we need
from context during testing.

```ts
describe("Groups", () => {
  it("should create", async (done) => {
    await withGroupContext(async ({ group }) => {
      expectGroup(group); // Specifics are not important for this example
    });
  });
});
```

What exactly does `withGroupContext` offer?

- A `let` variable we can use for storage to ensure we can cache results.
- A `Group` created through a utility function that requires `ResolverContext`.

```ts
// A helper context function to ensure all tests have access to the Group.
// This function can be placed anywhere, such as the end of the relevant
// `describe`, or at the bottom.

// One important bit, do not export `withGroupContext`. It relies
// on `let group`. It works well in one file,  but `npm test` will suffer
// polution.
let group: Group | undefined;
type TWithGroupContext = (
  context: ResolverContext & {
    group: Group;
  }
) => Promise<void>;
const withGroupContext = async (fn: TWithGroupContext) => {
  await withResolverContext(async (context) => {
    if (!group) {
      group = await resolverSaveGroup(context, {
        group: {
          description: "Generated through resolver tests",
          displayName: new Date().toLocaleString(),
        },
      });
    }

    await fn({ ...context, group });
  });
};
```

And `withResolverContext`, what is that?

```ts
import { Application } from "express";

export interface ResolverContext {
  // A set of system contexts, in case I need to alter the DB directly.
  context: SystemContext;
  // An initialized application we can hand off to supertest
  application: Application;
  // An auth token to include on requests
  authorization: string;
}
// Some local cache variables
let application: Application;
let context: SystemContext;
// Definition of what we'll offer
type TWithResolverContext = (context: ResolverContext) => Promise<void>;
// Implementation
export const withResolverContext = async (
  fn: TWithResolverContext
): Promise<void> => {
  if (!application) {
    application = await getApp();
  }
  if (!context) {
    context = await getSystemContext();
  }
  // This will be up to your requirements
  const authorization = await getAuthorization();

  await fn({
    context,
    application,
    authorization,
  });
};

let app: Application;
export const getApp = async (): Promise<Application> => {
  if (app) {
    return app;
  }

  // Whatever your application start up logic is, so long as it's async.
  // I started using async start up apps so database and message queue
  // schemas could run first. The pay off has been huge.
  app = await getApplication();
  return app;
};
```

These examples are super basic. A resolver context function that provides nothing more than the app,
authorization, and some utilities. Layered on that is a single group we created. It demonstrates
how I like to separate concerns and implementation into small reusable pieces. How that gets used is
next.

### Integration testing example

Here's the result of those context functions I've omitted past the basic concepts to focus on usage.
The lovely parts about writing this way to me are:

- You can fire any single test, and it always has all the data required.
- In a debugger breakpoint, you can stop the test and data will be left in the system.
- If you allow it to finish, all data will be cleared, even if you don't run the `delete` test.
  Pay special attention to the `delete` and `afterAll` handling at the end for how this works.

You'll notice a lot of types being imported from `../../generated/types`. We're wired up
to [GraphQL Code Generator](https://www.graphql-code-generator.com/) which produces
Typescript based on our earlier `groups.graphql` file. For details see my
Apollo server Express GraphQL API [example](https://github.com/lancegliser/node-express-apollo-graphql)
project.

```ts
import { print } from "graphql";
import gql from "graphql-tag";
import {
  Group,
  GroupMember,
  MutationAddMemberToGroupArgs,
  MutationDeleteGroupArgs,
  MutationRemoveMemberFromGroupArgs,
  MutationSaveGroupArgs,
  QueryGroupArgs,
} from "../../generated/types";
import {
  ResolverContext,
  expectGraphQLSuccessResponse,
  withResolverContext,
} from "../../../tests/graphql.utils";
import { GRAPHQL_URI } from "../../constants";
import supertest = require("supertest");

describe("Groups", () => {
  it("should create", async () => {
    await withGroupContext(async ({ group }) => {
      expectGroup(group);
    });
  });

  it("should update", async () => {
    await withGroupContext(async (context) => {
      const { group } = context;
      if (!group.id) {
        throw new Error(`Group.id is undefined`);
      }

      const { id, description } = group;
      const newName = `Test ${new Date().toLocaleString()}`;
      const result = await resolverSaveGroup(context, {
        group: {
          id,
          description,
          displayName: newName,
        },
      });
      expectGroup(result);
      expect(result.displayName).toBe(newName);
    });
  });

  // I've left this full example call and response example in case you want
  // to start writing your own API integration tests using supertest.
  it("should get", async () => {
    await withGroupContext(async ({ application, authorization, group }) => {
      if (!group.id) {
        throw new Error(`Group.id is undefined`);
      }

      const queryData: {
        query: string;
        variables: QueryGroupArgs;
      } = {
        // `gql` provides IDE support by turning it into AST tree allowing
        // error checking and refactoring support. `print` then turns that
        // AST tree back into a string we can use in our API call.
        query: print(gql`
          query Group($key: ID!) {
            group(key: $key) {
              id
              displayName
              createdAt
              createdBy
              updatedAt
              updatedBy
              members {
                id
                displayName
              }
            }
          }
        `),
        variables: { key: group.id },
      };

      // Super test uses our definition of the application to spin up
      // on a random port and allow external API testing.
      const response = await supertest(application)
        .post(GRAPHQL_URI)
        .set("authorization", authorization)
        .send(queryData);
      expectGraphQLSuccessResponse(response);
      const result = response.body.data.group;
      expectGroup(result);
      expect(result.id).toBe(group.id);
    });
  });

  it("should get groups for the user", async () => {
    await withGroupContext(async ({ application, authorization, group }) => {
      // ...
    });
  });

  describe("membership", () => {
    it("should add members", async () => {
      await withGroupsContext(
        async ({ groupA, groupB, groupBEdges, groupC, groupCEdges }) => {
          // ...
        }
      );
    });

    it("should remove membership", async () => {
      await withGroupsContext(
        async ({ application, authorization, groupA, groupC, groupCEdges }) => {
          // ...
        }
      );
    });

    // Remember those clean up functions I promised?
    // We can hook the `afterAll` up to our context to help tear things down.
    afterAll(async () => {
      await withGroupsContext(async (context) => {
        const { groupB, groupC } = context;
        await resolverDeleteGroup(context, { id: groupB.id! });
        await resolverDeleteGroup(context, { id: groupC.id! });
      });
    });

    // Here's an example of a context function at the end of a `describe`
    // block. I personally find it hard to deal with these long context
    // functions inside `describe` and `it` blocks. I like them to be
    // simple to read, and abstract out nearly everything I can that isn't
    // expectations normally. But, it does make it impossible for other
    // developers to reuse these, preventing the context polution I
    // warned you about, and some people prefer code colocated as closely
    // as possible.
    let groupB: Group | undefined;
    let groupBEdges: GroupEdge[] | undefined;
    let groupC: Group | undefined;
    let groupCEdges: GroupEdge[] | undefined;

    // A helper context function to ensure all tests have access to the
    // some groups with some structure.
    type TWithGroupContext = (
      context: ResolverContext & {
        groupA: Group;
        groupB: Group;
        groupBEdges: GroupEdge[];
        groupC: Group;
        groupCEdges: GroupEdge[];
      }
    ) => Promise<void>;
    const withGroupsContext = async (fn: TWithGroupContext) => {
      // We'll layer on top of the existing group to create two more
      // and make them related to the first.
      await withGroupContext(async (context) => {
        const { group: groupA } = context;

        // Setup B as a member
        if (!groupB) {
          groupB = await resolverSaveGroup(context, {
            group: {
              description: "Generated through resolver tests",
              displayName: `B - ${new Date().toLocaleString()}`,
            },
          });
        }
        if (!groupBEdges) {
          groupBEdges = await resolverAddMemberToGroup(context, {
            memberId: groupB._id!,
            targetSelection: {
              target: GroupTargetSelectionTarget.Existing,
              groupKey: groupA.id,
            },
          });
        }
        // Setup C as a member, and a child of B
        if (!groupC) {
          groupC = await resolverSaveGroup(context, {
            group: {
              description: "Generated through resolver tests",
              displayName: `C - ${new Date().toLocaleString()}`,
            },
          });
        }
        if (!groupCEdges) {
          groupCEdges = await resolverAddMemberToGroup(context, {
            memberId: groupC._id!,
            targetSelection: {
              target: GroupTargetSelectionTarget.Existing,
              groupKey: groupA.id,
              parentId: groupB._id,
            },
          });
        }

        await fn({
          ...context,
          groupA,
          groupB,
          groupBEdges,
          groupC,
          groupCEdges,
        });
      });
    };
  });

  // Back outside of the `describe("membership")`, we need to clean up
  // our remaining group. Which should be tested all on it's own to make
  // sure it works.
  it("should delete", async () => {
    await withGroupContext(async (context) => {
      const { group } = context;
      if (!group.id) {
        throw new Error(`Group.id is undefined`);
      }

      const result = await resolverDeleteGroup(context, {
        key: group.id!,
      });
      expectGroup(result);
    });
  });

  // We can hook in through `afterAll` to ensure that even if the
  // delete test isn't run we still clean up after ourselves.
  afterAll(async () => {
    await withGroupContext(async (context) => {
      const { group } = context;
      // We just have to try / catch
      try {
        await resolverDeleteGroup(context, { key: group.id! });
      } catch (error) {
        // Because we would expect there to be "group not found" errors
        throwUnexpectedDeleteErrors(error);
      }
    });
  });
});

// A helper context function to ensure all tests have access to a Group
let group: Group | undefined;
type TWithGroupContext = (
  context: ResolverContext & {
    group: Group;
  }
) => Promise<void>;
const withGroupContext = async (fn: TWithGroupContext) => {
  await withResolverContext(async (context) => {
    if (!group) {
      group = await resolverSaveGroup(context, {
        group: {
          description: "Generated through resolver tests",
          displayName: new Date().toLocaleString(),
        },
      });
    }

    await fn({ ...context, group });
  });
};
```

What do you think? Is it heresy, to create local scope cache and pass it around for testing?
Do the layered context functions provide more simple abstractions for maintenance? Do
you prefer to see the context functions outside of the `describe` blocks?

Send me a
[tweet](https://twitter.com/intent/tweet?text=%40lancegliser%20RE%3A%20Layered%20context%20functions%20for%20testing.%20I...).

> I like it when people say hi.

Yes Aaron Mahnke. I stole your line. It's simple, lovely, and true.
Thanks for all the [stories](https://www.lorepodcast.com/) 👻📖.


Ramblings of a full stack developer

Blog entries

Using environment specific values in Azure DevOps Helm task

Kubernetes - Required ports for CertManager and Nginx Ingress controller

Azure DevOps - My work items

Creating dynamic AMCharts 5 themes from Material UI themes

GraphQL file upload mutations

Using layered context functions to share objects for Jest integration testing