

We love using go to build our backend services. Among many reasons one is the fact that when you build your application into a docker image, it contains literally nothing except your application. Many other languages or frameworks require a complete linux to be packaged into the container (or even a virtual machine running on a linux!), making it bigger and more complex. 

## Tiny blackbox?

While we find it very awesome when our build pipeline spits out a 6mb docker image that contains basically an executable and a folder with some compiled HTML/CSS/JS initially there seems to be a downside: You cannot get at the contents of the running container as easily as when you can actually connect with a shell into the container. You see it is running in a `docker ps`  but it's a bit of a black box. Of course you can mount volumes to have the application store information outside the container, but you may have forgotten to do so and now some bit of information is locked up in there? Worry not, there is a way to get at it. 

Lets say our server generates a pdf file with a name based on a timestamp (so we do not know the name). The container is running, the pdf is saved inside the containers filesystem. Now we want to get it out for inspection.

So first we need to know the id of the container. So we run `docker ps` to get our container id. Say it is "8f87b75b584e". 


## Docker export to the rescue

Docker supports a command that will take the filesystem of a container and export it to STDOUT. This is useful for instance to export the filsystem from inside a container into a tar file:

```bash
docker export 8f87b75b584e > my_container.tar
```

You can also use it to export the filesystem into the tar executable to output *what files* are contained inside like so: 

```bash
 docker export 8f87b75b584e | tar t
```

This will output something like the following:

```txt
.dockerenv
app/
app/server
app/documents/1590404561193689502.pdf
app/public/
app/public/assets/favicon.ico
app/public/assets/logo.svg
app/public/index.html
app/public/static/
app/public/static/css/
app/public/static/css/main.5de28820.chunk.css
app/public/static/css/main.5de28820.chunk.css.map
app/public/static/js/
app/public/static/js/2.20a9197e.chunk.js
app/public/static/js/2.20a9197e.chunk.js.LICENSE.txt
app/public/static/js/2.20a9197e.chunk.js.map
app/public/static/js/main.c34e0be6.chunk.js
app/public/static/js/main.c34e0be6.chunk.js.map
app/public/static/js/runtime-main.7eede39e.js
app/public/static/js/runtime-main.7eede39e.js.map
dev/
dev/console
dev/pts/
dev/shm/
etc/
etc/hostname
etc/hosts
etc/mtab
etc/resolv.conf
proc/
sys/
```

So now we know what it is called: `1590404561193689502.pdf` That makes it possible to copy the file from the running docker container to the hosts filesystem:

```bash
docker cp 8f87b75b584e:app/documents/1590404561193689502.pdf test.pdf
```

Voila! Having these tools at hand takes away what might otherwise be a drawback to the ultra lean docker images possible when packaging a go application in an image based on "scratch". 

How to access files in a docker container built on scratch


When building a frontend, like any piece of software, it is good practice to create an automated suite of tests to repeatedly verify, that everything is still working as intended. For a React frontend there are several mechanisms what kind of tests you can write and run, including: **snapshots**. 

A snapshot is the detailed output of rendering a component to HTML with maybe a few additional infos.  

It is easy enough to do, testing your components and views using jest and a few additional helpers like enzyme or react-test-renderer. Such a test looks something like this:

```javascript
import * as React from 'react'
import * as renderer from 'react-test-renderer'
import ErrorBox, { ErrorBoxProps } from './ErrorBox'

const props: ErrorBoxProps = {
    errors: [
        'Lorem ipsum dolor sit amet',
        'Phasellus rutrum leo',
    ],
    errorTitle: 'TestCategory',
}

describe('ErrorBox Component', () => {
    it('should render correctly', () => {
        const component = renderer.create(<ErrorBox {...props} />)
        expect(component).toMatchSnapshot()
    })

})
```

So we expect the component which gets rendered to match a snapshot (which is automatically created in and subsequently read from a `__snapshots__` directory next to the test file)



This mode of testing sounds all too simple. All it does is make sure, that the rendered output is the same as before - how is this useful? 

The power of the snapshot test lies in three effects.

## First: freeze a manual test

The snapshot may be a bit cryptic if there is lots of JS objects as props, but it should still be **read**. By you. This way, what the snapshot *represents* is a frozen *manual* test, that everything is still exactly the way **you** tested it and found it ok. 

Changes should be viewed and made sure that they are what you would expect from the code changes you made and that they are error free. Once you have checked that, what you are comitting is in fact an updated manual test again. Just updating the snapshot with no manual check makes them basically useless. 

## Second: catching side effects
When you have a component that is an agregation of several other components, then a change in one of them might cause problems. So by changing a child component, the parent will either be the same as before (good) or break, because something has changed and needs to be checked (also good). 

This is also true of component libraries you use, if they have breaking changes you have to re-check your code in the places where things changed too. 

## Third: Learning from snapshots

Reading the contents of a snapshot file is of course done to try to find bugs. But at the same time, you also learn about the internals of the components you are using. 

React has spawned an ecosystem for truly reusable component libraries like material-ui which provide such a great basis to build applications from powerful building blocks very quickly. But there is a lot of (well crafted) magic going on in that simple button you are using. 

Snapshots provide you a window into what is actually going on inside a component, which may help you better understand the interface it has. Many components consist of nested HTML elements and you can pass prop values or assign styles to different elements inside the component. This may sometimes be hard to grasp until you make a snapshot test and look inside to *see* the hierarchy and where your style may have gone to. 

## How nothing was a great result

We were once tasked with cleaning up in a project where two teams had worked on a web application. Initially a react savvy frontend dev (this was a few years ago) started off by building a component library of common UI elements from scratch. Then however, one team chose to continue with Typescript, the other went with flow. 

We had the dubious pleasure of combining the two copies back into one library that supported both TS and flow. The great thing was that there were snapshot tests! We converted JS to TS and changed class based components to functional ones. In the end when we were done it was great to see what the difference was in the snapshots: Nothing. 

Everything was still green. 

That was a powerful moment, as much as we had changed - for the rest of the application it was actually the same and we could **prove** it. 

## An example

A snapshot file storing the above component rendered with react-test-renderer will look like this:

```HTML
// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`ErrorBox Component should render correctly 1`] = `
<ul
  className="MuiList-root ErrorBox"
>
  <div
    className="MuiListSubheader-root ErrorBoxSubheader"
  >
    <h6
      className="MuiTypography-root MuiTypography-subtitle1"
    >
      error.title.TestCategory
    </h6>
  </div>
  <div
    className="MuiBox-root MuiBox-root-1"
  >
    <li
      className="MuiListItem-root MuiListItem-gutters"
      disabled={false}
    >
      <div
        className="MuiListItemIcon-root"
      >
        <svg
          aria-hidden={true}
          className="MuiSvgIcon-root"
          focusable="false"
          viewBox="0 0 24 24"
        >
          <circle
            cx="12"
            cy="12"
            r="8"
          />
        </svg>
      </div>
      <div
        className="MuiListItemText-root"
      >
        <p
          className="MuiTypography-root MuiTypography-body1"
        >
          error.message.Lorem ipsum dolor sit amet 
        </p>
      </div>
    </li>
  </div>
  <div
    className="MuiBox-root MuiBox-root-2"
  >
    <li
      className="MuiListItem-root MuiListItem-gutters"
      disabled={false}
    >
      <div
        className="MuiListItemIcon-root"
      >
        <svg
          aria-hidden={true}
          className="MuiSvgIcon-root"
          focusable="false"
          viewBox="0 0 24 24"
        >
          <circle
            cx="12"
            cy="12"
            r="8"
          />
        </svg>
      </div>
      <div
        className="MuiListItemText-root"
      >
        <p
          className="MuiTypography-root MuiTypography-body1"
        >
          error.message.Phasellus rutrum leo
        </p>
      </div>
    </li>
  </div>
</ul>
`;
```

So what can I see here? 

1) The title and the error messages are not supposed to be the text itself, but i18n identifiers, which is why there is the `"error.message.Phasellus rutrum leo"` thing. 
2) Oh, look, the ListItem from MaterialUI is actually inserting an SVG as the bullet instead of using a HTML list! Sure, that makes the style more independent of the browser, but also changes how we can style it. We may be tempted to try and style it the wrong way if we did not know that ListItem is not actually an `<li>` tag. 

So do not discard the simple snapshot test too easily, it offers worthwhile benefits in itself. Writing it is easy, reading the snapshot does take a bit of diligence to spot abnormalities, but I claim this takes less than tracing an error back to its source in a larger context. 




How snapshot tests matter

Jedes Projekt braucht seine Helden.

<p>Telefon <a href="tel:+4940609457970" target="_self" data-scheme="tel:" data-href="+4940609457970">+49 40 609457970</a><br>E-Mail <a target="_self" href="mailto:info@qubidu.com" data-href="mailto:info@qubidu.com" data-scheme="">info@qubidu.com</a></p>

<p>Qubidu GmbH<br>Auf dem Sande 1<br>20457 Hamburg<br>Deutschland</p>

<p>Qubidu GmbH<br>Hertener Str. 39<br>45657&nbsp;Recklinghausen<br>Deutschland</p>

<p class="text-right">Alle Rechte vorbehalten,&nbsp;&copy; Qubidu GmbH&nbsp;2021<br><a target="_self" href="/impressum" data-href="/impressum" data-scheme="">Impressum</a>&nbsp;|&nbsp;<a target="_self" href="/datenschutz" data-href="/datenschutz" data-scheme="">Datenschutz</a>&nbsp;| <a href="https://editor.qubidu.com" target="_blank" data-scheme="https://" data-href="editor.qubidu.com">Login</a><br></p>

How to access files in a docker container built on scratch

Tiny blackbox?

Docker export to the rescue

Kontakt

Hamburg (Zentrale)

Ruhrgebiet