Supporting fixture setup like Pytest

[stroiman]

Pytest has support for fixture setup in a way I've not seen in other test frameworks. I've never really used testify (used ginkgo/gomega for most go test work), but wanted to give it a go.

When I saw the suite functionality, and thinking about how Go works e.g., with embeds, I wondered if testify suites could support setup in a way similar to pytest fixtures.

I wanted to do some experiments/research before writing, but I just saw you request feedback for v2, so I decided to write sooner than later.

Maybe you already support this? Maybe it's even a well documented pattern I would have known about if I'd read the docs ...

But if not, this maybe this could be inspiration to something to think about for v2.

Pytest fixtures

In Pytest, a "fixture" is just a function that returns a value, and is identified by an attribute. Fixtures are automatically injected into test functions, based on parameter name matching fixture name. But fixtures can also depend on other fixtures, so there's some kind of "dependency injection" going on, but one "instance" of the fixture is being created for one test.

This example is copied directly from the pytest fixture page

import pytest

class Fruit:
    def __init__(self, name):
        self.name = name

    def __eq__(self, other):
        return self.name == other.name

@pytest.fixture
def my_fruit():
    return Fruit("apple")

@pytest.fixture
def fruit_basket(my_fruit):
    return [Fruit("banana"), my_fruit]

def test_my_fruit_in_basket(my_fruit, fruit_basket):
    assert my_fruit in 

I didn't write a lot of python, but I used it for a tool operating on files. I had a fixture for a mocked file system. And another fixture depending on the mock-fs fixture. This would create a input file with contents (returning the file name). An actual test could depend on both. The "test input file" fixture would be used for input to the command, and the mock-fs fixture would be used to verify the state of the mocked file system.

And this worked really well.

Testify support?

Typical xunit frameworks I've worked with, tests are wrapped in classes that has a setup. You can create an inheritance hierarchy, which can create a specialised fixture. But you have just one string of fixtures depending on one other fixture.

Ginkgo, and the type of tools that it comes from, RSpec, mocha, jasmine, have kindof the same problem. Rather than an inheritance hierarchy, you have a list of parent contexts, so you still have the same limitation.

But with a testify fixture being a go struct with fields, maybe a suite could depend on other suites? and have setup functions run in a proper order.

For the shared fixture to work, they'd need to be pointers, or at least the underlying data must be. And there would need to be some kind of dependency injection framework ...

But, this was in my opinion the nicest way of operating with useful reusable setup code for tests.

Another benefit is DX. When you have a test, and want to find the fixture code, it's a matter of "go to definition" in your editor, rather than the OOP, go to parent class, or nested-spec approach of finding the parent context.