Writing tests for blocks

Welcome to the community @Graham_Vasquez!

There are a bunch of testing frameworks you can use for custom blocks. I believe the Airtable team uses Jest for their testing, and is one I’ve been using myself. The site has great documentation for how to get started, but in a nutshell, the first steps you would need to take are:

1. Install Jest (or whatever test package you want)
2. Write a test file, called myBlock.test.js (if using Jest, I believe all files need to end with .test.js for them to be found).
3. Run Jest. If you’re in the directory with your custom block, typing jest should do the trick. If using npm, you can also add custom flags to a script and then run npm test.

Another popular unit testing package for Javascript is Mocha, but I think Jest was designed more closely with React in mind.

If this answers your question, please consider marking it as “solution”. If not, I’m happy to work with you further. Thanks!

Hi Matt,

Thanks for the guidance. I am running into a bit of an issue in that when I try to run the tests it always fails giving me the following error:

@airtable/blocks can only run inside the block frame

Any thoughts on how I can test the Airtable functions with my tests?

Thanks :slightly_smiling_face:

Ah, I see, this now looks a lot more limiting than I originally thought. I haven’t seen anything in the documentation or the community (yet) to indicate that this “offline” approach with Jest, or other similar package, would be possible for your Airtable-specific function code.

The next route I might suggest is a little more convoluted and not as nice, but should get the job done? You could build a debug/test mode into your custom block (e.g. a “Run tests” button) that appears only while you’re developing the block. This block could then iterate over any tests you’ve written, and since running within the Block itself, should have access to the Airtable functions.

Tests could be written much the same way, though probably needing plain Javascript, instead of Jest/other testing framework code. Keep tests in separate *.test.js files that you then import into the helper function that runs the tests (i.e. just calling each test function sequentially).

We’re still exploring the best way to test blocks. A few ideas:

• A “test mode” inside your block, as @Matthew_Thomas suggests.
• Write the block in a way that lets you write unit tests for the logic separate from the blocks environment. For example, a timeline block may have a layout function that takes Array<{recordId, startDate, endDate}> and returns information about how to lay out those items e.g. Array<{recordId, x, y}>. You could write unit tests for this.
• End-to-end tests with something like https://www.selenium.dev or https://www.cypress.io. In this case the block would need to be released in a live base. You could use remotes to create a separate test base.

I haven’t yet done this myself, but ran into a similar concern with testing an app using specialized hooks. (I’m assuming it’s the hooks and their expected context that is giving you trouble.)

import { useHook } from 'some-lib'

const MyComponent = ({ foo, useSomeHook = useSome }) => {
  const { bar, baz } = useSomeHook()
  return (
    <div
  )
}

Then you kinda ignore it in your actual app code, but when doing testing or using storybookJS to isolate key states, you inject a fake mock hook that spits out whatever values you want to exercise :slightly_smiling_face:

Hopefully this is helpful!