little cubes

How to test TypeScript type definitions with Jest

You can add tests for your static TS types right next to your regular Jest tests

Have you ever toiled to get the TypeScript types just right on a particular function and thought to yourself, “I wish I could write a test to make sure that I don’t break this type definition next time I edit this function”? Me too! In this post I’ll give you thorough instructions on how you can do just that.

SetupSection titled: Setup

The library we’re going to use to execute these static type tests is one that I made called jest-tsd. It’s a wrapper around tsd to make it really easy to use with Jest.

  1. Install jest-tsd and its peer dependency.

    Terminal window
    # With yarn
    yarn add --dev jest-tsd @tsd/typescript
    # Or with npm
    npm i -D jest-tsd @tsd/typescript
    # Or with pnpm
    pnpm i -D jest-tsd @tsd/typescript
  2. Exclude .test-d.ts files from your TypeScript compiler build.

    • This is important because your type definition test files will intentionally add tests that throw TS compiler errors
    • In your tsconfig.json, add:
    "exclude": ["**/*.test-d.ts"],
  3. Add a new Jest test for your type definitions

    src/init-translation.test.js
    import {expectTypeTestsToPassAsync} from 'jest-tsd'
    it('should not produce static type errors', async () => {
    await expectTypeTestsToPassAsync(__filename)
    })

The Function Under TestSection titled: The Function Under Test

I want to use a non-trivial example type definition in this post so that I can write some non-trivial type tests. The rest of this section is explaining how that function works, feel free to skip if you don’t care.

The function I’ve chosen here, initTranslation takes 1 or 2 arguments. Its purpose is to return a translate function that can be called to map a translation key to text that can be shown on a UI for a particular language or region. The optional second parameter provides a way to avoid defining the same UI string multiple times.

src/init-translation.ts
// Function type overload 1
export function initTranslation<G extends Record<string, string>>(
genericDict: G,
): (key: keyof G) => string
// Function type overload 2
export function initTranslation<G extends Record<string, string>, P extends Record<string, string>>(
genericDict: G,
createPageSpecificDict?: (link: (key: keyof G) => string) => P,
): (key: keyof G | keyof P) => string
// Actual function implementation that is generic enough to satisfy
// the type constraints of all function type overloads.
export function initTranslation(
genericDict: Record<string, string>,
createPageSpecificDict?: (link: (key: any) => string) => Record<string, string>,
): (key: string) => string {
/* implementation */
}
  • The first argument is a dictionary object whose keys & values are all strings.
  • The second argument is a function with a link() param that returns a similar dictionary.
    • The difference is that this second object can invoke the link() function as a value of the object.
    • link() gets passed a key from the first parameter of initTranslation in order to reuse that already defined UI string.
    • In the actual implementation, link() is secretly an identity function. Its only purpose is to provide strong typing of translation keys. Changing a linked key should throw a type error.

Here’s a simple example of how it might be used:

let translate = initTranslation(
{'foo.bar': 'Foobar'},
(link) => ({
'foo.baz': link('foo.bar'),
'one.two': '1 2',
}),
)

Writing a Type Definition testSection titled: Writing a Type Definition test

jest-tsd has a variety of different assertions available to you. Here we’ll make use of expectType and expectError.

src/init-translation.test-d.ts
import {expectType, expectError} from 'jest-tsd'
import {initTranslation} from './init-translation'

First a series of tests for the single parameter version of initTranslation:

src/init-translation.test-d.ts
let translate1 = initTranslation({'foo.bar': 'Foobar'})
it('should accept key defined in first param dictionary', () => {
expectType<(key: 'foo.bar') => string>(translate1)
})
it('should throw error for key not included in dictionary', () => {
expectError(translate1('123'))                          
Argument of type '"123"' is not assignable to parameter of type '"foo.bar"'
})

And then similar tests for the two param version:

src/init-translation.test-d.ts
let translate2 = initTranslation(
{'foo.bar': 'Foobar'},
(link) => ({
'foo.baz': link('foo.bar'),
'one.two': '1 2',
}),
)
it('should accept keys defined in either first or second param dictionary', () => {
expectType<(key: 'foo.bar' | 'foo.baz' | 'one.two') => string>(translate2)
})
it('should throw error for key not included in either dictionary', () => {
expectError(translate2('123'))                          
Argument of type '"123"' is not assignable to parameter of type '"foo.bar" | "foo.baz" | "one.two"'
})

Finally test to ensure that the link() function will only accept keys previously defined in the first param dictionary:

src/init-translation.test-d.ts
it('Link function should only accept keys defined in first param dictionary', () => {
expectError(initTranslation(
{ 'foo.bar': 'Foobar' },
(link) => ({ 'one.two': link('one.one') })                                  
Argument of type '"one.one"' is not assignable to parameter of type '"foo.bar"'
))
})
it('Link function should not accept keys defined in second param dictionary', () => {
expectError(
initTranslation({ 'foo.bar': 'Foobar' },
(link) => ({
'one.one': 'One',
'one.two': link('one.one'),                       
Argument of type '"one.one"' is not assignable to parameter of type '"foo.bar"'
})),
)
})

Tests in TypeScript?Section titled: Tests in TypeScript?

I can hear you saying, “but Zach, you made a big deal in your post on Jest testing mistakes saying that tests should always be written in JavaScript, not TypeScript!“.

And I stand by that. Writing tests in TS makes them harder to maintain over time and most of the time adds no value over their JS counterparts.

The actual Jest test file described above is still written in JavaScript!

ConclusionSection titled: Conclusion

Next time you take the time to write complicated generic types for some utility function in your shared code, I hope you’ll also take a little time to write tests for those types!