testcase alternatives and similar packages
Based on the "Testing Frameworks" category.
Alternatively, view testcase alternatives based on common mentions on social networks and blogs.
-
dockertest
Write better integration tests! Dockertest helps you boot up ephermal docker images for your Go tests with minimal work. -
gnomock
Test your code without writing mocks with ephemeral Docker containers ๐ฆ Setup popular services with just a couple lines of code โฑ๏ธ No bash, no yaml, only code ๐ป -
embedded-postgres
Run a real Postgres database locally on Linux, OSX or Windows as part of another Go application or test -
gotest.tools
A collection of packages to augment the go testing package and support common patterns. -
go-testdeep
Extremely flexible golang deep comparison, extends the go testing package, tests HTTP APIs and provides tests suite -
testza
Full-featured test framework for Go! Assertions, fuzzing, input testing, output capturing, and much more! ๐ -
GoSpec
Testing framework for Go. Allows writing self-documenting tests/specifications, and executes them concurrently and safely isolated. [UNMAINTAINED] -
jsonassert
A Go test assertion library for verifying that two representations of JSON are semantically equal -
assert
:exclamation:Basic Assertion Library used along side native go testing, with building blocks for custom assertions -
fluentassert
DISCONTINUED. Extensible, type-safe, fluent assertion Go library. Do NOT use it (sic!). -
gogiven
gogiven - BDD testing framework for go that generates readable output directly from source code
CodeRabbit: AI Code Reviews for Developers

Do you think we are missing an alternative of testcase or a related project?
Popular Comparisons
README
<!-- START doctoc generated TOC please keep comment here to allow auto update --> <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> Table of Contents
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
testcase
The testcase
package provides tooling to apply BDD testing conventions.
Getting Started
Example
The examples managed in godoc, please read the documentation example section for more.
A Basic example:
package mypkg_test
import (
"testing"
"github.com/you/mypkg"
"github.com/stretchr/testify/require"
"github.com/adamluzsi/testcase"
)
func TestMyTypeIsLower(t *testing.T) {
s := testcase.NewSpec(t)
s.NoSideEffect()
myType := func(t *testcase.T) *mypkg.MyType {
return &mypkg.MyType{}
}
var subject = func(t *testcase.T) bool {
return myType(t).IsLower(t.I(`input`).(string))
}
s.When(`input has upcase letter`, func(s *testcase.Spec) {
s.LetValue(`input`, `UPPER`)
s.Then(`it will be false`, func(t *testcase.T) {
require.False(t, subject(t))
})
})
s.When(`input is all lowercase letter`, func(s *testcase.Spec) {
s.LetValue(`input`, `lower`)
s.Then(`it will be true`, func(t *testcase.T) {
require.True(t, subject(t))
})
})
}
Modules
- httpspec
- spec module helps you create HTTP API Specs.
- fixtures
- fixtures module helps you create random input values for testing
Summary
DRY
testcase
provides a way to express common Arrange, Act sections for the Asserts with DRY principle in mind.
- First you can define your Act section with a method under test as the subject of your test specification
- The Act section invokes the method under test with the arranged parameters.
- Then you can build the context of the Act by Arranging the inputs later with humanly explained reasons
- The Arrange section initializes objects and sets the value of the data that is passed to the method under test.
- The Arrange section initializes objects and sets the value of the data that is passed to the method under test.
- And lastly you can define the test expected outcome in an Assert section.
- The Assert section verifies that the action of the method under test behaves as expected.
Then adding an additional test edge case to the testing suite becomes easier, as it will have a concrete place where it must be placed.
And if during the creation of the specification, an edge case turns out to be YAGNI, it can be noted, so visually it will be easier to see what edge case is not specified for the given subject.
The value it gives is that to build test for a certain edge case, the required mental model size to express the context becomes smaller, as you only have to focus on one Arrange at a time, until you fully build the bigger picture.
It also implicitly visualize the required mental model of your production code by the nesting. You can read more on that in the nesting section.
Modularization
On top of the DRY convention, any time you need to Arrange a common scenario about your projects domain event, you can modularize these setup blocks in a helper functions.
This helps the readability of the test, while keeping the need of mocks to the minimum as possible for a given test. As a side effect, integration tests can become low hanging fruit for the project.
e.g.:
package mypkg_test
import (
"testing"
"my/project/mypkg"
"github.com/adamluzsi/testcase"
. "my/project/testing/pkg"
)
func TestMyTypeMyFunc(t *testing.T) {
s := testcase.NewSpec(t)
// high level Arrange helpers from my/project/testing/pkg
SetupSpec(s)
GivenWeHaveUser(s, `myuser`)
// .. other givens
myType := func() *mypkg.MyType { return &mypkg.MyType{} }
s.Describe(`#MyFunc`, func(s *testcase.Spec) {
var subject = func(t *testcase.T) { myType().MyFunc(t.I(`myuser`).(*mypkg.User)) } // Act
s.Then(`edge case description`, func(t *testcase.T) {
// Assert
subject(t)
})
})
}
Stability
- The package considered stable.
- The package use rolling release conventions.
- No breaking change is planned to the package exported API.
- The package used for production development.
- The package API is only extended if the practical use case proves its necessity.