Skip to main content

​
Onboarding

Tusk will do three things when you sync your repo:
  1. Embed your repo for semantic understanding
  2. Set up the Language Server Protocol for retrieving codebase context
  3. Set up a test environment for the agent to self-lint and run its tests
During automated setup, Tusk will iterate on the configuration if it encounters errors. If setup encounters an issue it can’t resolve automatically, you’ll see a “Failed” or “Needs Input” status.You can:
  • Review the error - Click into the environment to see what went wrong
  • Provide missing information - Often failures are due to missing environment variables
  • Retry setup - After addressing the issue, click Retry to start again
  • Contact support - For complex issues, reach out to support@usetusk.ai
See Test Execution Environments for more details.
  • VP or Director of Engineering who is in charge of quality engineering or developer productivity
  • Staff/Principal Software Engineer who is most familar with your testing best practices
  • Senior DevOps Engineer who is most familiar with your organization’s CI/CD pipeline
It takes 2 minutes of time to do the initial setup of connecting your version control platform and syncing your repo(s). Most organizations will be fully ready to kick off with a customized Tusk agent after half a day of effort.
Yes. Reach out to your Tusk point of contact or support@usetusk.ai and we’ll get Tusk set up on-prem for you. As to be expected, this will require more implementation time.

​
Product

Yes. You can choose which specific test cases you’d like to commit or create a PR for from within the Tusk web app.
Yes. Tusk will generate new unit tests if the changes are substantial enough to warrant new tests.
Yes. Tusk will look at existing unit tests in the PR/MR and extend them while also looking for edge cases that you have not covered. We make sure to de-dupe tests by comparing all generated tests to existing tests in the PR/MR and repo.
Tusk automatically filters out tests that are “low value” (e.g., testing implementation instead of behavior), duplicates of existing tests, or failing to run properly even after multiple iterations on the test code.
There’s no hard limit on the size of PRs/MRs that Tusk can write tests for, but in general test quality is best when PRs/MRs are less then 50 files modified or 2,500 lines of code added and deleted.
Tusk looks for common refactoring patterns (e.g., high ratio of files modified vs. lines changed per file, high number of string replacements, PR/MR info mentioning words like “refactor” and “reorganize”, etc.) in the PR/MR to determine if it is a large scale refactor.Tusk will skip test generation for large scale refactors if the “Skip large refactor PRs” feature is enabled in your repo’s Test Check Configuration.
By default, Tusk has default unit testing guidelines that we consider to be best practices. You can override these guidelines by adding custom instructions in “Symbol selection guidelines” in the Test execution tab of your repo’s settings.
This scenario happens infrequently but is caused by certain edge cases (listed below). In this scenario, Tusk decides to fail gracefully and create a separate test file for the symbol instead of dropping the tests altogether.Potential causes:
  1. Tusk did not find the original test file
  2. Tusk failed to incorporate tests into the original test file
  3. Tusk found that the original test file has errors when running
Report this issue to us over Slack or at support@usetusk.ai and we’ll resolve the issue as soon as possible. In the event of #1 and #2, we will investigate to determine if it is a bug and, if so, push a fix.
Tusk calculates coverage by running test files directly associated with each source file (i.e., tests that directly call the functions being tested), not your entire test suite. Running the full suite twice (before and after Tusk’s changes) would add significant latency to PR checks and CoverBot runs.This means the coverage percentages shown by Tusk may be lower than your full suite since we don’t capture indirect coverage from other tests in your codebase. Since we only measure direct coverage, the gains (“+X%”) can appear larger than the actual improvement to your full suite coverage.For example, if Tusk shows a file going from 60% → 85% (+25%), in some cases your full test suite might show 75% → 95% (+20% actual gain). Even when this happens, Tusk’s direct tests are still valuable because they won’t disappear if someone refactors unrelated tests that were incidentally exercising this code.This tradeoff has worked well for most of our customers, as it balances actionable metrics with faster feedback. If you have specific coverage calculation requirements, please reach out to our team at support@usetusk.ai.

​
Billing

GitHub or GitLab username. You can activate seats for the usernames that belong to your organization/group in Settings > Seats in the Tusk web app.Usernames without an active Tusk seat will not have Tusk’s test generation triggered in the PR/MRs that they create.
We have a minimum of 3 seats on our Business plan. Startups may opt for our Team plan, which has no seat minimum. Most midmarket and enterprise companies choose to start with 15-30 seats for a more comprehensive evaluation of Tusk’s impact on code coverage and bugs prevented.
Firstly, make sure that you’re the billing admin for your Tusk organization. If not, Tusk will prompt you to contact the admin via email to upgrade your plan.
  1. In Settings > Billing, click “Manage subscription”
  2. In the panel that opens up, increase the number of seats using the ’+’ toggle
  3. Click “Review changes”
  4. Confirm adding the seats
  5. In Settings > Seats, click “Sync members” to fetch usernames for your organization/group
  6. Toggle on the team member’s seat under the Status column
If you’re on an Enterprise or Legacy plan, contact your Tusk representative or support@usetusk.ai, and we will update your subscription.