testcase alternatives and similar packages
Based on the "Testing Frameworks" category.
Alternatively, view testcase alternatives based on common mentions on social networks and blogs.
-
Testify
A toolkit with common assertions and mocks that plays nicely with the standard library -
GoConvey
Go testing in the browser. Integrates with `go test`. Write behavioral tests in Go. -
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 ๐ป -
go-vcr
Record and replay your HTTP interactions for fast, deterministic and accurate tests -
testfixtures
Ruby on Rails like test fixtures for Go. Write tests against a real database -
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. -
testza
Full-featured test framework for Go! Assertions, fuzzing, input testing, output capturing, and much more! ๐ -
go-testdeep
Extremely flexible golang deep comparison, extends the go testing package, tests HTTP APIs and provides tests suite -
dbcleaner
Clean database for testing, inspired by database_cleaner for Ruby -
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 -
gogiven
gogiven - BDD testing framework for go that generates readable output directly from source code -
schema
Quick and easy expression matching for JSON schemas used in requests and responses -
gosuite
Test suites support for standard Go1.7 "testing" by leveraging Subtests feature
Static code analysis for 29 languages.
Do you think we are missing an alternative of testcase or a related project?
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.