Run tests

• Click the gutter Run Test icon, select Run, and then select the fuzz testing configuration (for example, go test -fuzz FuzzTest).

  If the testing fails, you can click the link to the testdata directory to see what input has failed the test.

  To run go test with the failing seed corpus entry, open the file from the testdata directory, click the Run Fuzzing icon in the gutter, and select the necessary configuration.

  

1. Create a breakpoint by clicking the gutter on the necessary line.

   Alternatively, click the line where you want to create a breakpoint and press CtrlF8.

2. Click Run | Debug.

3. In the Debug popup window, select the desired run/debug configuration.

1. Press Alt00 to open the Commit tool window and click Show Commit Options .

2. Under the Advanced Commit Checks menu, next to the Run Tests option, click Choose configuration and select which configuration you want to run.

   

Use the following options on the Run toolbar of the tab for the run configuration:

• Click or press CtrlF2 to terminate the process immediately.

• Right-click a test on the tab for the run configuration in the Run tool window and select Run 'test name'.

• Click on the Run toolbar or press CtrlF5 to rerun all tests in a session.

• Click on the Run toolbar to rerun only failed tests.

  Hold Shift and click to choose whether you want to Run the failed tests again or Debug them.

  You can configure the IDE to trigger tests that were ignored or not started during the previous test run together with failed tests. Click on the Run toolbar and enable the Include Non-Started Tests into Rerun Failed option.

In GoLand, you can enable the autotest-like runner: any test in the current run configuration restarts automatically after you change the related source code.

• Click Rerun Automatically on the test results toolbar to enable the autotest-like runner.

1. In the editor, click the gutter on the line where you want to set a breakpoint.

   There are different types of breakpoints that you can use depending on where you want to suspend the program. For more information, refer to Breakpoints.

2. Right-click the gutter icon next to the failed test and select Debug 'test name'.

   The test will rerun in debug mode. After that, the test will be suspended, allowing you to examine its current state.

   You can step through the test to analyze its execution in detail.

   

• You can run individual table tests by using the Run icon () in the gutter. Also, you can navigate to an individual table test from the Run tool window.

  Current support of table tests has following limitations:

  • The test data variable must be a slice, an array, or a map. It must be defined in the same function as the t.Run call and must not be used after initialization (except for the range clause in the for loop).

  • The individual test data entry must be a struct literal. Loop variables used in a subtest name expression must not be used before the t.Run call.

  • A subtest name expression can be test data string field, a concatenation of test data string fields, or a fmt.Sprintf() call with %s and %d verbs.

    For example, in the following code snippet, fmt.Sprintf("%s in %s", tc.gmt, tc.loc) is a subtest name expression.

    for _, tc := range testCases {
        t.Run(fmt.Sprintf("%s in %s", tc.gmt, tc.loc), func(t *testing.T) {
            loc, err := time.LoadLocation(tc.loc)
            if err != nil {
                t.Fatal("could not load location")
            }
            gmt, _ := time.Parse("15:04", tc.gmt)
            if got := gmt.In(loc).Format("15:04"); got != tc.want {
                t.Errorf("got %s; want %s", got, tc.want)
            }
        })
    }