Skip to main content

incubator​

Greetings, this is incubator.

In normal cases, you won't be utilizing myself.

You will be using either mockto, komondor, or zucchini.

However, you may need me if you encounter a situation where mocktomata is unable to work with your code.

Because, I am specialized in developing plugins.

mocktomata supports plugins to extends its capability. In fact, its ability to handle JavaScript types such as string, array, function, object, promise etc., are all implemented by plugins.

While mocktomata tries to handle most of the cases out of the box, there are limits to that because what it tries to solve is really a NP problem.

So when you encounter a case that mocktomata doesn't work, you will need to find a plugin, or create one.

To understand how to create a plugin, you can refer to the plugin documentation. Here, I'm going to show you how to utilize me to implement and test your plugin.

config()​

The first thing you need to do is to ask me to load your plugin by calling config():

import { incubator } from 'mocktomata'
import { activate } from '.'

incubator.config({
  plugins: [
    ['your-plugin', activate], // or 'your-plugin'
    'other-plugin'
  ]
})

The signature of config() is:

config({ plugins: Array<name: string | [name: string, activate: (context) => void]> })

The plugins property is an array accepting either name or [name, activate]. Which one to use depends on where are you writing your tests.

If you pass in just name, it will try to load the plugin package.

Given that you are likely writing your plugin and writing your tests together, most likely you will use the second one and pass in your plugin's activate() function directly.

As shown in the example above, you can load other plugins to create a specific test environment.

Note that the general configuration mechanism does not affect me.

Once you have your plugin loaded, you can start writing tests.

incubator()​

The primary way I work is quite similar to mockto:

import { incubator } from 'mocktomata'

incubator('...', (specName, spec, reporter) => {
  test(specName, async () => {
    const s = await spec({ a: 1 })
    // ...
    await spec.done()
  })
})

The difference is, instead of running the test in auto mode and save the SpecRecord as needed, I run the test twice: once in save mode, and once in simulate mode.

The SpecRecord is also not saved to a file, but is kept in memory.

The signature is:

incubator(specName, specOptions?, handler: (specName, spec, reporter) => void)

Where specName must be unique within one test file, and specOptions is a Spec.options.

The spec() is a function as well as an object holder other functions and properties:

reporter is a MemoryLogReporter.

So what I do is running the test twice so that it goes through the whole life cycle of your plugin, to make sure it is working as expected.

I also support incubator.save() and incubator.simulate() to run the test only in save or in simulate mode.

They are useful when you want to focus on one part of the lifecycle.

(You use incubator.simulate() for testing error cases, as there won't be any SpecRecord to simulate against).

incubator.sequence()​

Beside incubator(), I support this incubator.sequence() call which allows you to run the Spec in save and in simulate mode, in the way you want it to:

import { incubator } from 'mocktomata'

incubator.sequence('...', (specName, { save, simulate }, reporter) => {
  test(specName, async () => {
    {
      const s = await save(subject)
      // ...
      await save.done()
    }
    {
      const s = await simulate(subject)
      // ...
      await simulate.done()
    }
  })
})

You can use this to test some corner cases, such as error cases, or masking.