Programming language: Go
License: Apache License 2.0
Tags: Testing     Testing Frameworks    
Latest version: v0.5.0

testcase alternatives and similar packages

Based on the "Testing Frameworks" category.
Alternatively, view testcase alternatives based on common mentions on social networks and blogs.

Do you think we are missing an alternative of testcase or a related project?

Add another 'Testing Frameworks' Package


<!-- 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 -->

Mentioned in Awesome Go GoDoc Build Status Go Report Card codecov


The testcase package provides tooling to apply BDD testing conventions.

Getting Started


The examples managed in godoc, please read the documentation example section for more.

A Basic example:

package mypkg_test

import (




func TestMyTypeIsLower(t *testing.T) {
    s := testcase.NewSpec(t)

    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))


  • httpspec
    • spec module helps you create HTTP API Specs.
  • fixtures
    • fixtures module helps you create random input values for testing



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.
  • 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.


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.


package mypkg_test

import (



    . "my/project/testing/pkg"

func TestMyTypeMyFunc(t *testing.T) {
    s := testcase.NewSpec(t)

    // high level Arrange helpers from my/project/testing/pkg
    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


  • 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.

Case Study About testcase Package Origin

Reference Project