The Temporal Go SDK provides a test framework to facilitate testing Workflow implementations. The framework is suited for implementing unit tests as well as functional tests of the Workflow logic.
The following code implements unit tests for the
To run unit tests, we first define a "test suite" struct that absorbs both the
basic suite functionality from testify
suite.Suite and the suite functionality from the Temporal test framework via
testsuite.WorkflowTestSuite. Because every test in this test suite will test our Workflow, we
add a property to our struct to hold an instance of the test environment. This allows us to initialize
the test environment in a setup method. For testing Workflows, we use a
Next, we implement a
SetupTest method to set up a new test environment before each test. Doing so
ensures that each test runs in its own isolated sandbox. We also implement an
where we assert that all mocks we set up were indeed called by invoking
Finally, we create a regular test function recognized by "go test" and pass the struct to
The simplest test case we can write is to have the test environment execute the Workflow and then evaluate the results.
s.env.ExecuteWorkflow(...) executes the Workflow logic and any invoked Activities inside the
test process. The first parameter of
s.env.ExecuteWorkflow(...) contains the Workflow functions,
and any subsequent parameters contain values for custom input parameters declared by the Workflow
Note that unless the Activity invocations are mocked or Activity implementation replaced (see Activity mocking and overriding), the test environment will execute the actual Activity code including any calls to outside services.
After executing the Workflow in the above example, we assert that the Workflow ran through completion
via the call to
s.env.IsWorkflowComplete(). We also assert that no errors were returned by asserting
on the return value of
s.env.GetWorkflowError(). If our Workflow returned a value, we could have
retrieved that value via a call to
s.env.GetWorkflowResult(&value) and had additional asserts on that
When running unit tests on Workflows, we want to test the Workflow logic in isolation. Additionally, we want to inject Activity errors during our test runs. The test framework provides two mechanisms that support these scenarios: Activity mocking and Activity overriding. Both of these mechanisms allow you to change the behavior of Activities invoked by your Workflow without the need to modify the actual Workflow code.
Let's take a look at a test that simulates a test that fails via the "Activity mocking" mechanism.
This test simulates the execution of the Activity
SimpleActivity that is invoked by our Workflow
SimpleWorkflow returning an error. We accomplish this by setting up a mock on the test environment
SimpleActivity that returns an error.
With the mock set up we can now execute the Workflow via the
s.env.ExecuteWorkflow(...) method and
assert that the Workflow completed successfully and returned the expected error.
Simply mocking the execution to return a desired value or error is a pretty powerful mechanism to isolate Workflow logic. However, sometimes we want to replace the Activity with an alternate implementation to support a more complex test scenario. Let's assume we want to validate that the Activity gets called with the correct parameters.
In this example, we provide a function implementation as the parameter to
Return. This allows us to
provide an alternate implementation for the Activity
SimpleActivity. The framework will execute this
function whenever the Activity is invoked and pass on the return value from the function as the result
of the Activity invocation. Additionally, the framework will validate that the signature of the "mock"
function matches the signature of the original Activity function.
Since this can be an entire function, there is no limitation as to what we can do here. In this
example, we assert that the
value param has the same content as the value param we passed to the Workflow.