Skip to main content

mockto​

Now it's time to show you everything I can do.

Let me introduce myself one more time.

I am one of the four mocktomata in the mocktomata family.

I specialize in writing tests.

In introduction, I showed you this example:

import axios from 'axios'
import { mockto } from 'mocktomata'

mockto('get friends', (specName, spec) => {
  test(specName, async () => {
    const s = await spec(axios)

    const friends = await getFriends(s, 'miku')
    expect(friends.map(f => f.name)).toEqual(['luka', 'rumi', 'len', 'ren'])

    await spec.done()
  })
})

You call me first and write your test inside the handler. By doing that, you can describe the test only once ("get friends" in the example). That value is passed to the handler as specName, so you can use it in your test description (test(specName, ...)).

Beside that, I am very similar to komondor.

In fact, while every mocktomaton do things a bit differently, and are good at specific use cases, under the hood we provide almost the same functionality and functions.

So when each mocktomaton introduce ourselves, we will focus on how we differ and provide the functionality to you.

Here are the things that we share. We will just describe what they are, and you can find out more about them following the links:

Let's take a look at my main API in detail:

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

This is the common way to utilize me.

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

The handler is where you use the spec() to write your test.

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

reporter is a MemoryLogReporter.

I will run the Spec in auto mode.

This behavior can be changed through configuration.

There are 4 variants of this call:

  • mockto.live(...)
  • mockto.save(...)
  • mockto.simulate(...)
  • mockto.mock(...)

They run the Spec in those mode respectively. The configuration will not change the behavior if I am called this way.

mockto.cleanup()

This is the cleanup() function.

alias as mt

Besides calling me as mockto, you can also call me as mt:

import { mt } from 'mocktomata'

mt(...)

komondor said that people think his name is too long to type so he wants to be alias as kd. And as he does that, he also give me this mt alias.

Oh well.

Tips and Tricks​

Here are some tips and tricks to help you become more productive when using me.

TDD Workflow​

If you are writing code TDD style, use mockto.live() throughout your red-green-refactor process. After you are done, change it to mockto() and run the test again.

Lazy TDD Workflow​

Instead of using mockto.live(), you can use mockto.save(). This will save you from running the test again after updating to mockto().

Streamlined Workflow​

Instead of using mockto.live() or mockto.save(), you can use mockto() directly but do not add the done() call until you are done refactoring. Your test runner will complain until you call done(), but you can safely ignore that as you know what you are doing.

Update One Test Record​

Change mockto() to mockto.save(), run the test, and switch it back.

Preserving Passed Tests​

If the external dependency is not stable or no longer available (for the time being or require specific condition or permission), you can consider changing some tests from mockto() to mockto.simulate() so that the test behavior is preserved.

When using mockto.simulate(), configuration will not change it behavior thus will not accidentally overwrite the record. However, this should be done with care, because you are essentially changing the test to a simple mocked unit test.

Use Configuration To Update Record​

Refer to configuration tips and tricks session for ways to update multiple records.