
_I recently started hosting AMA-style cafe chats with developers at various stages of their journey, about software engineering and anything else within my technical experience. Below are some notes from the chat on Nov 16th, 2022._

Imagine you feed this to your front-end i18n library:

```ts
const i18enStrings = {
  "home.title": "Life, universe, and everything",
  "home.subtitle": "A guide",
};

const i18itStrings = {
  "home.title": "La vita, l'universo, e tutto quanto",
  "home.subtitl": "Una guida",
};
```

## Challenge #1: can you guess what happens when the user switches from English to Italian?

On the user side, either of these is likely to happen:

1. the typo hides the second string from the i18n library and the site lacks the subtitle
2. the i18n library is smart enough to fall back on a default, and the subtitle stays in English

What's more interesting though is what happens — or rather **doesn't** happen
— on the developer side:

1. the dev environment doesn't crash;
2. the build doesn't break;
3. tests don't break;
4. the pre-production environment doesn't crash;
5. the production environment doesn't crash.

## Challenge #2: how do you fix this?

And _what_ do you fix?

The typo isn't the problem. The problem is that all the checkpoints on the way to prod are blind to the bug.

Ask yourself:

1. how can I, at the very least, make future instances of this problem crash prod?
2. better: how can I make them crash preprod?
3. better: how can I make them break tests?
4. better: how can I make them break the build?
5. better: how can I make them annoy the IDE to the point that it shouts at me even before I save?

In other words: picturing an imaginary line from dev to prod going from left to right, you want shift detection and prevention/correction as left as possible. [^1]

## Challenge #3: how do you shift this bug to the left?

If you can write a test to guard against a problem, good.

If you can write a type, great.

Here it's such a small diff that someone unaware of all the above could easily dismiss it as minor. Assuming English strings are the authoritative ones regarding keys:

```diff
  const i18enStrings = {
    "home.title": "Life, universe, and everything",
    "home.subtitle": "A guide"
  }

+ type I18Strings = typeof i18enStrings

- const i18itStrings = {
+ const i18itStrings: I18nStrings = {
    "home.title": "La vita, l'universo, e tutto quanto",
    "home.subtitl": "Una guida"
  }
```

Which results in:

```sh
error TS2322: Type '{ "home.title": string; "home.subtitl": string; }' is not assignable to type '{ "home.title": string; "home.subtitle": string; }'.
  Object literal may only specify known properties, and '"home.subtitl"' does not exist in type '{ "home.title": string; "home.subtitle": string; }'.

8   "home.subtitl": "Una guida",
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

[^1]: [DevOps: Shift Left to Reduce Failure](https://devops.com/devops-shift-left-avoid-failure/)


How two lines of TypeScript can make a bug go from “undetected in production” to “impossible to introduce”


_I recently started hosting AMA-style cafe chats with developers at various stages of their journey, about software engineering and anything else within my technical experience. Below are some rough & rapid-fire notes from the chat on Oct 21st, 2022._

## Getting started

You can test at various levels, from an individual function that knows nothing about browsers to an entire application running in a real browser and hitting real network services.

Testing small or medium-sized interactions in a simulated browser environment is a good middle ground — approachable yet useful.

Pick a basic interaction and write it down:

> "when button 'About' is clicked, modal with information appears".

Stick to interactions where the UI is both the input and the output channel.

<details>
  <summary>About “channels”...</summary>

- A test's "input channel" and "output channel" are terms I made up; probably better ones exist; related: "test boundaries".
- When testing a pure function, input and output channels are obvious: arguments in, return value out.
- When testing a callback function, it's a little less obvious: arguments in, callback argument out.
- When testing a UI, it's even less obvious: user action in, UI change out; or: user action in, API request out; or: push notification in, UI change out; and so on.
</details>

[Install & set up](https://testing-library.com/docs/react-testing-library/setup) `jest`, `jest-environment-jsdom`, `@testing-library/react`, and `@testing-library/jest-dom`.

Pick a component high enough in your app's tree to support the chosen interaction. Don't be afraid to use `<App/>` itself.

Write a `<component-you-picked>.test.tsx` file containing a `test("when button 'About' is clicked'...)` where you `render()` the component, `user.click()` the button, and `expect()` that the intended change happened in the UI.

The UI change might happen on the next iteration of the JavaScript event loop; use `await waitFor(() => { expect(...) })` to account for it.

Use `screen.debug()` to inspect the state of the DOM at any point of the test.

Continue with interactions that involve the network and repeat.

<details>
  <summary>Choosing output channels when network interactions are involved...</summary>

- "When button is clicked, API request is sent" → the network is the output channel.
- "When button is clicked, table gets populated with server data" → the UI is the output channel.
- "When button is clicked, API request is sent and table gets populated with the returned data" → nothing bars you from looking at multiple output channels.
  </details>

Arrange something that handles the network request **within the test environment**.

- Since you're getting started, use [nock](https://github.com/nock/nock) — it's the least magical option and forces you to understand what's going on.
- `nock()` a request and its response, `render()` the component, `user.click()` the button that triggers the network request, `expect()` the UI changes and/or that the request was made.
  - **if you're using Node 18** and your frontend code calls the global `fetch` instead of one imported from [isomorphic-fetch](https://www.npmjs.com/package/cross-fetch) or [cross-fetch](https://www.npmjs.com/package/isomorphic-fetch)): Node 18 introduces a global `fetch`, so your tests might end up invoking that, and [nock can't mock it yet](https://github.com/nock/nock/issues/2336). Fix by adding `import "cross-fetch/polyfill"` in a jest `setupFile` or by importing `fetch` from `cross-fetch` in application code rather then relying on the global. Alternatively, you can use the mocking facilities of Node 18's new HTTP client [undici](https://undici.nodejs.org/en/), but those are unlikely to match `nock`'s for a while.

## Getting better

As you become more comfortable with the testing machinery, explore other ways of simulating parts of your system inside the test environment:

- Your API service is written in Node and lives next to the React app as part of a monorepo? Launch the actual server in `beforeAll()`, point your components to it by passing them an `apiBaseUrl` prop or context value, and let them interact with the real (albeit sandboxed) thing.
- If your API service is an external? Mock it with something like [MSW](https://github.com/mswjs/msw).
- `jest.mock()` and `spyOn()` things that your components affect in ways other than the network, e.g. third-party SDKs
- Zero in on non-UI parts of your applications and test them independently of React: vanilla JS components, reducers, ...
  - The more logic you manage to move away from React components and into functions (especially pure functions), the bigger benefits you'll reap in terms of architecture and maintainability of the code base, as well as of the quality of your flow (since tests are faster and easier to understand).


“I’ve got a React codebase, I want to introduce tests, where do I start?”


_I recently started hosting AMA-style cafe chats with developers at various stages of their journey, about software engineering and anything else within my technical experience. Below are some rough & rapid-fire notes from the chat on Oct 21st, 2022._

## "Why test?"

Tricky question because it puts you in the mindset of writing test code after application code (rarely you'd think IRL of testing something that's not there).

- Better question: _Why write down your goal before starting to work on it?_
- TDD used to be called "Test-First Design"; good but not great (the word _test_ is still there); attempts at rebranding as "Behaviour-Driven Development" sadly failed.
- Ideally someone with a magic want would replace `test(description, tester)` with `rule(definition, validator)` everywhere.

## "If you look at two typical hours of your coding, what's taking most of that time?"

For me, checking that a change I made does what I want, and checking that a change that I made doesn't break something else. In other words: validation.

- Not just a time cost — the frequent context switch has high attentional cost.
- Automating validation shifts a large chunk of the time cost to the machine. Well written tests (running in <5s) also save the attentional cost.

## "My application is still simple. Maybe I can postpone writing tests for a while longer still?"

- Has it happened yet that something that was working before suddenly stopped working and you don't know why? If so, guess what that means.
- Any form of automated validation shrinks the time between defect introduction and defect detection/correction. If you imagine your codebase's evolution as an arrow growing with time, automated validation helps increase the work you do near the pointy end of the line instead of repeatedly jumping back on the line to fix things that used to work.

## Critical thinking not optional

- Test all the things, then? Not so fast. A situation might not just call for automated validation (e.g. exploring a problem space) or not call for it _yet_ (e.g. integrating with pieces you have no control over that will drastically influence the choice of a testing strategy).
- Even when automated validation is called for, example-based tests aren't necessarily the best form; sometimes you may want snapshot-based tests (whether at the data or the visual level) or even [property-based](https://github.com/dubzzz/fast-check) tests.


TDD and (vs?) testing


[web3-mock](https://github.com/DePayFi/web3-mock) supports Cypress and JSDOM test environments out of the box. However, I prefer Playwright to those as it provides a compelling set of benefits: familiar Jest matchers, a fixture-based runner, and execution in multiple real browser environments. Getting web3-mock to work with Playwright requires setup that is minimal but not obvious, hence this quick note.

The test definitions configures the mock and then interact with the page:

```typescript
import { test } from '@playwright/test'

test('test wallet connection', async ({ page }) => {
  await mockWeb3(page, () => {
    // @ts-ignore
    Web3Mock.mock({
      blockchain: 'ethereum',
      accounts: { return: ['0xd73b04b0e696b0945283defa3eee453814758f1a'] },
    })
  })

  await page.goto('http://localhost:3000/')
  await page.locator('text=Sign in').click()
  await page.locator('text=Connected').waitFor()
})
```

The `mockWeb3()` call causes the `web3-mock` library plus the mock configuration to be loaded whenever a page is navigated to, but before the page's own scripts are run:

```typescript
import { Page } from '@playwright/test'
import { readFileSync } from 'fs'

const mockWeb3 = async (page: Page, fn: Function) => {
  await page.addInitScript({
    content:
      readFileSync(
        require.resolve('@depay/web3-mock/dist/umd/index.bundle.js'),
        'utf-8',
      ) +
      '\n' +
      `(${fn.toString()})();`,
  })
}
```

Why the ugly string concatenation, when we could call `addInitScript` twice, once for injecting the library, the next for injecting the mock configuration? Because the order of execution of scripts added with `addInitScript` is not defined, so the library might get loaded after (the attempt at) using it.


MM

Tagged “qa”