Installation

You install three things: the core, one container adapter for your DI container (or the trivial Bag), and — if your tests use mocks — one mock adapter for your mocking library.

Which language?

Mokkit ships for .NET and for Go. The package layout follows the same rule in both: a dependency-free core, one container adapter for how your subject is wired, and — if your tests use mocks — one mock adapter for your mocking library.

C#

Skip ahead — the rest of this page is the .NET package matrix.

Go

Requires Go 1.27+ (the token API is built on generic methods). The core module has zero dependencies; each adapter is its own module, so a suite pays only for what it imports:

go get github.com/GrafGenerator/go-mokkit          # core: chains, stages, tokens, bag, allure
go get github.com/GrafGenerator/go-mokkit/container/mokkitgomock    # go.uber.org/mock
go get github.com/GrafGenerator/go-mokkit/container/mokkitmockery   # mockery / testify
go get github.com/GrafGenerator/go-mokkit/container/mokkitminimock  # gojuno/minimock
go get github.com/GrafGenerator/go-mokkit/container/mokkitdo        # samber/do v2
go get github.com/GrafGenerator/go-mokkit/container/mokkitdig       # uber-go/dig

Module	You need it when…
go-mokkit	always — the core, the hand-wired bag container, and the Allure reporter
…/mokkitgomock	your mocks are generated by mockgen
…/mokkitmockery	your mocks are mockery-generated testify mocks
…/mokkitminimock	your mocks are minimock-generated
…/mokkitdo, …/mokkitdig	your subject is wired by that DI container

One tooling note: build tools that parse Go source — golangci-lint, mockery — must themselves be built with Go 1.27 or newer, or they will refuse the generic-method syntax.

A minimal unit-test setup

Core + Microsoft DI + NSubstitute is a common starting point:

dotnet CLI

dotnet add package Mokkit
dotnet add package Mokkit.Containers.Microsoft.Extensions.DependencyInjection
dotnet add package Mokkit.Containers.NSubstitute

PackageReference

<ItemGroup>
  <PackageReference Include="Mokkit" Version="0.4.0" />
  <PackageReference Include="Mokkit.Containers.Microsoft.Extensions.DependencyInjection" Version="0.4.0" />
  <PackageReference Include="Mokkit.Containers.NSubstitute" Version="0.4.0" />
</ItemGroup>

The [MokkitCapture] source generator ships inside the Mokkit package (under analyzers/dotnet/cs), so referencing Mokkit is all you need to use it — nothing extra to install.

Package matrix

Package	You need it when…
Mokkit	Always. The core: Stage, Arrange/Act/Inspect, captures, the [MokkitCapture] generator.
Mokkit.Containers.Microsoft.Extensions.DependencyInjection	Your system-under-test is wired with Microsoft DI.
Mokkit.Containers.Autofac	…wired with Autofac.
Mokkit.Containers.CastleWindsor	…wired with Castle Windsor.
Mokkit.Containers.Bag	You just need to hold a few pre-built instances (e.g. e2e clients) — no DI, no auto-wiring.
Mokkit.Containers.Moq	Your tests mock with Moq.
Mokkit.Containers.NSubstitute	…mock with NSubstitute.
Mokkit.Containers.FakeItEasy	…mock with FakeItEasy.
Mokkit.Containers.Common	Shared base for the mock adapters — pulled in automatically; you don’t reference it directly.

How to choose

• Which container adapter? Match your production wiring. If the SUT is resolved from Microsoft DI, use the Microsoft DI adapter so the real graph is exercised and mocks are bridged into it. If your test only needs to hand back a couple of pre-built objects (typical for black-box e2e), the Bag container is the zero-dependency choice.
• Which mock adapter? Match your mocking library — one per test project. (You can even mix a mock container with a DI container; see Containers & the mock→DI bridge.)
• Multiple SUTs? One test project can use several containers together; you compose them when you build the Stage. See The Stage & lifecycle.

Ready to write one? Head to the Quickstart.