Testix

The Test-First Mocking Framework

Testix is the Test-First (TDD) Friendly Mocking framework for Python, meant to be used with pytest

Warning

These docs are under development!

Testix is special because it allows you to specify what your mock objects do, and it then enforces your specifications automatically. It also reduces (albeit not entirely) mock setup.

Other frameworks usually have a flow like this:

  1. setup mock

  2. let code do something with mock

  3. assert mock used in correct way

Testix flow is a bit different

  1. setup mock objects

  2. specify exactly what should happen to them using a Scenario context

Quick Example

Here is a quick example of how Testix works.

# to test the Chatbot class, we pass it a mock socket called "sock"
tested = chatbot.Chatbot(Fake('sock'))

# create a Scenario context
# inside, you specify exactly what the unit should do with the objects its handed
with Scenario() as s:

    s.sock.recv(4096) >> 'request text'  # unit must call sock.recv(4096).
                                         # this call will return 'request text'
    s.sock.send('response text')

    # call your unit's code
    tested.go()


# Scenario context ends, and verifies everything happened exactly as specified
# No more, no less

Note that you do not have to setup sock.recv or sock.send - once sock is set up, it will generate other mock objects automatically as you go along with it. Only “top level” mock objects need to be setup explicitly.

The Scenario object does essentially two things:

  1. setup our expectations (these are the s.sock.* lines)

  2. enforce our expectations (this is done by the with statement)

Want to know more? Read the :doc:tutorial.

Some Advanced Features

Testix natively and elegantly supports testing for

  1. Context managers (with statement constructs)

  2. async code

  3. async context managers (async with statement constructs)

  4. Hooks - allowing you to simulate asynchronous events that happen between two lines of your code

Advantages

Testix has been written to promote the following

  1. Readability - the expectations are very similar to the actual code that they test (compare s.sock.recv(4096) with the standard sock.recv.assert_called_once_with(4096)

  2. Test Driven Development friendliness: if you use sock.recv.assert_called_once_with(4096), you must use it after the code has run. With Testix, you specify what you expect, and the asserting is done for you by magic.

What are you waiting for?

Go to the reference or read the Tutorial

Read More