​
Overview

When you enable Tusk’s test generation for a repo, Tusk follows an out-of-the-box set of rules as to when and how it should generate unit tests for your PR/MRs.

We’ve created these rules according to the typical engineering team’s workflow.

To modify the rules to fit your team’s workflow better, go to the Repositories page, click the gear icon on a repo, and edit the repo settings under the Configuration tab.

​
Test Generation Features

Test Check Enabled

  • This is enabled by default when you first enable test generation on a repo. Make sure to keep this setting checked if you want Tusk to generate unit tests for PRs in this repo.
  • Most teams will never have to modify this setting.

Run On Draft PRs

  • Disabled by default. Some engineering teams use draft PRs as they are developing a feature so they can push changes incrementally before marking the PR as ready for review.
  • If your software engineers prefer that Tusk runs earlier in the development lifecycle by generating unit tests for commits on draft PRs, enable this feature.

Skip Large Refactor PRs

  • Enabled by default. Tusk automatically evaluates whether a commit is primarily a large scale code refactor. If it is a refactor, Tusk will skip generating tests for the commit since tests are not likely expected to be included in the PR/MR.
  • Disabling this setting means that Tusk will not check to see if a commit is a large scale refactor before generating unit tests.

Restrict Tests to PR Diff

  • Disabled by default. Tusk’s test generation is by default scoped to the symbols modified in the PR/MR but it does not restrict its generated test cases to the scope of the PR/MR’s diff. This is ideal for teams that optimize for increasing unit test coverage because it means that engineers can backfill tests for untested parts of their codebase in a piecemeal approach, even if their PR/MR’s changes are minor.
  • If enabled, Tusk enters a “Strict Mode” where the test cases it generates is restricted to only what is relevant for the diff in the PR/MR. This is ideal for teams that care more about preventing bugs in their PR/MR.

Fast Test Generation

  • Disabled by default. When enabled, Tusk will generate its test results (e.g., test description, test code, pass/fail, execution output of individual tests) 3-5 minutes quicker. This is ideal for teams that merge PR/MRs fast and want to see Tusk’s output as soon as possible.
  • The caveat here is that there could be an added latency of 3-5 minutes for Tusk’s commit to show up on the PR/MR when the engineer clicks “Incorporate tests”. This is because Tusk uses that time to combine the individual tests into full test file(s), a process which typically happens before results are shown when this setting is disabled.

​
Base Branches to Ignore

Your engineers may be working off of base branches like release or staging and may not want Tusk to be generating unit tests for those PRs.

Use this field to specify base branches that Tusk should ignore. Note that you can use glob patterns to match base branches with a specific naming convention.

​
Blocked Directories

You may not want Tusk to be able to read or access files in a certain directory for your repo, either for security reasons or because it is not relevant for Tusk to generate tests.

Use this field to specify the directory paths that you would like to block Tusk from accessing. Note that you can use .gitignore syntax to block directories.