komondor

Hi, This is komondor.

I used to be a guard dog.

But nowadays, I'm one of the four mocktomata in the mocktomata family.

If you find my name is too long, you can also call me kd.

While mockto specialized for testing, I'm more general purposed and versatile.

Here is how to write the same test from introduction:

import axios from 'axios'
import { komondor } from 'mocktomata'

test('get friends', async () => {
  const spec = komondor('get friends')
  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()
})

afterAll(komondor.cleanup)

You can see mockto and me are pretty similar.

The main difference is that you call me within the test, and you have to repeat the specName (if it is the same as your test description, which is the case most of the time).

All mocktomata provides similar functionalities.

Here are the things we share, for reference:

• Spec: specification of behavior we record and replay.
• spec subject : the subject to record the behavior from (axios in the example).
• SpecRecord: The record we saved for a Spec.
• spec(): the function to create a spec subject .
• reporter: a MemoryLogReporter from standard-log.
• mode: the SpecMode the code is currently running in.
• done(): the function to indicate the Spec is done.
• cleanup(): a overall clean up function.
• maskValue(): the function to mask sensitive value from logs and SpecRecord.
• ignoreMismatch(): the function to tell us to ignore specific changes.

My API look like this:

komondor(specName, specOptions?): spec

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

I returns a spec() function, which is also an object holding the other functions and properties:

• spec.reporter (note that this is different than mockto)
• spec.mode
• spec.done()
• spec.maskValue()
• spec.ignoreMismatch()

I will run the Spec in auto mode.

This behavior can be changed through configuration.

There are 4 variants of this call:

• komondor.live(...)
• komondor.save(...)
• komondor.simulate(...)
• komondor.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 kd

In my past live, people say my name is too long. So this time, I have an alias kd:

import { kd } from 'mocktomata'

test('...', async () => {
  const spec = kd(...)
})

Tips and Tricks

komondor shares the same tips and tricks as mockto.

But it also has its own when it is used in production.

Recorded Demo

Using komondor can record all interactions to any external system. That means you can create a record, and replay it in a live demo.

Note that the browser side support is not yet available in 7.0.

Live Debug Recording

If your customer reports a problem, you can get into a live debug session with your customer and turn on komondor recording. Then you can record the complete behavior and reproduce it later on.

Note that the browser side support is not yet available in 7.0.

Architecture Consideration

To use komondor in production code, there are some architecture best practice you can follow to make it easier.

Clean Architecture

Dependency Injection

Design your application with dependency injection in mind will make it very easy to use komondor in production.

All you need to do as passing in the spec'd instance of your dependency, and it will work as is. When the time is right, call spec.done() to save the record.