> For the complete documentation index, see [llms.txt](https://protocol-labs.gitbook.io/testground/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://protocol-labs.gitbook.io/testground/master/table-of-contents/writing-test-plans/paramaters-and-testcases.md).

# Parameters and test cases

## Adding an additional test case

Parameters and test cases are defined in the `manifest.toml` file of every test plan. Let's have a look once again at the `quickstart/manifest.toml` file and add two test cases to the bottom of the file:

**$TESTGROUND\_HOME/plans/quickstart/manifest.toml**

```
...


[[testcases]]
name = "smallbrain"
instances = { min = 1, max = 200, default = 1 }

  [testcases.params]
  word = { type = "string", default = "never" }
  num = { type = "int", default = 2 }
  feature = { type = "bool", default = false }

[[testcases]]
name = "bigbrain"

  [testcases.params]
  word = { type = "string", default = "always" }
  num = { type = "int", default = 10000000 }
  feature = { type = "bool", default = false }
```

?> Feel free to add your own `galaxybrain` test case as well!

You can confirm that the [testground client](/testground/master/table-of-contents/concepts-and-architecture/daemon-and-client.md#testground-client) is able to parse the manifest, and enumerate the cases it declares:

```bash
$ testground plan list --testcases | grep quickstart
quickstart    smallbrain
quickstart    bigbrain
```

We would like to take these two cases out for a spin. First, let's prepare our code. Open our `quickstart` plan program and deal with these parameters!

!> This snippet is routing both test cases to the same function. In practice, you will want to run different logic for each test case!

As you can see, a test plan a simple executable that conforms to the [simple Testground contract](/testground/master/table-of-contents/concepts-and-architecture/test-structure.md#the-test-plan-less-than-greater-than-testground-contract), which the SDK facilitates. This makes it super easy to debug and develop. There's beauty in simplicity!

**$TESTGROUND\_HOME/plans/quickstart/main.go**

```go
package main

import (
	"github.com/testground/sdk-go/run"
	"github.com/testground/sdk-go/runtime"
)

func main() {
	run.InvokeMap(map[string]interface{}{
		"bigbrain":   test,
		"smallbrain": test,
	})
}

func test(runenv *runtime.RunEnv) error {
	var (
		num     = runenv.IntParam("num")
		word    = runenv.StringParam("word")
		feature = runenv.BooleanParam("feature")
	)

	runenv.RecordMessage("I am a %s test case.", runenv.TestCase)
	runenv.RecordMessage("I store my files on %d servers.", num)
	runenv.RecordMessage("I %s run tests on my P2P code.", word)

	if feature {
		runenv.RecordMessage("I use IPFS!")
	}

	return nil
}
```

The time has come now to run these test cases. Let's run it!

```bash
$ testground run single --plan quickstart \
                        --testcase smallbrain \
                        --builder exec:go \
                        --run local:exec \
                        --instances 1 \
                        --wait
```

?> Try using different runners. This command executes the plan with the `local:exec` runner and `exec:go`builder, but it works just as well with the `local:docker` runner or the Kubernetes `cluster:k8s`runner (for which you will need to use the `docker:go` builder!


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://protocol-labs.gitbook.io/testground/master/table-of-contents/writing-test-plans/paramaters-and-testcases.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.