Test Suggestions Perspective
The Test Suggestions perspective helps you select the most relevant tests for your project. It offers two complementary approaches:
- Change-Based Test Suggestions (Similarity Scoring and Test Impact analysis) recommend tests that cover recently changed or issue-related code, helping you focus testing effort on risky areas.
- Change-Independent Test Suggestions (Pareto Optimization) helps you build an optimized smoke test suite by ranking tests to maximize code coverage within a given time budget.
Both views are described in the following:
Prerequisite: Testwise Code Coverage
Change-independent test suggestions and the coverage-based part of change-based suggestions (the Tests Covering Risks tab) require testwise code coverage to be uploaded to Teamscale. This coverage data links individual tests to the methods they execute. See Providing Testwise Coverage for more details on uploading testwise coverage data.
Change-based test suggestions also work without testwise coverage. This mode is called Similarity Scoring (the Related Test Implementations tab). In that mode, Teamscale matches test code against production code based on terminology similarity, so no coverage upload is needed.
Change-Based Test Suggestions
Change-based test suggestions help you find tests that are relevant to recent code changes. The workflow consists of defining which code is risky, selecting test candidates, and then reviewing the suggested tests.
Defining Risks
The left panel lets you define what constitutes risky code by enabling one or more of the following filters:
- Path: Restrict the analysis to a specific code location.
- Changes Since (Baseline): Consider all code changed since a given commit or timestamp. You can further narrow this to only untested changes to focus on test gaps.
- Issue-Related Changes (Issue Query): Include code that was changed to implement the selected issues.
The Risk Treemap on the right visualizes the selected risks. Orange areas represent risky (changed/untested) code and gray areas are unchanged.
Selecting Test Candidates
The Test Candidates section at the bottom lets you define which tests Teamscale can choose from. You can filter candidates by test query, name, duration, result, and test sources. The toggle Use only tests with testwise coverage restricts candidates to tests that have testwise coverage data available.
Once you have defined your risks and candidates, click Select Tests From Candidates to start the analysis.
Results: Related Test Implementations (Similarity Scoring)
The Related Test Implementations tab shows tests whose content is terminologically similar to the risky code. This technique is called Similarity Scoring and does not require testwise code coverage. Each test is scored by Content Relevance—a higher score means greater textual similarity.
You can optionally exclude tests that have testwise coverage available and are known to cover the risks with the Exclude N tests with known risk coverage toggle. These tests are listed in the Tests Covering Risks tab. So by default, these tests are not repeated on this tab.
You can select a subset of the list with the Number of tests (budget) selector. If the runtime of each test case in the list is known, the total test runtime of the selection is shown next to the selector.
Similarity Scoring requires that the tests are written in one of the test frameworks supported by Teamscale.
Stop Words
Before processing tests and code changes for Similarity Scoring, Teamscale removes so-called stop words. These are words like public, import or void that do not help match tests to a code change. You can change the stop words used for a particular programming language by providing a stop word list file. Place a UTF-8-encoded text file named <language>.txt (for example, kotlin.txt) into the stop-words directory relative to the Teamscale installation or working directory. The file should contain one stop word per line—typically language keywords, common standard library identifiers, and other terms that appear frequently across all code in that language. Teamscale picks up the file automatically on the next restart.
Results: Tests Covering Risks (Test Impact Analysis)
The Tests Covering Risks tab is available when testwise code coverage has been uploaded. It shows tests that have actual coverage of the risky methods. This view includes:
- Risk Treemap: Shows which risky methods are covered (green) vs. uncovered (red/orange) by the suggested tests.
- Risk Coverage over Time: A Pareto curve showing how risk coverage increases as more tests are added. The curve flattens over time, illustrating diminishing returns.
- Test Budget: A slider to constrain the total execution time. The statistics below show the resulting time, number of tests, and risk coverage as percentages.
- Test Table: Lists suggested tests with their partition, duration, and the number of additionally covered risky methods (Additional Risk Coverage).
Change-Independent Test Suggestions (Pareto Optimization)
Change-independent test suggestions help you build a coverage-optimized smoke test suite. The goal is to find the smallest set of tests that achieves the highest code coverage within a given time budget, independent of any particular code change.
Selecting Tests
In the Select Tests tab, use the test query filter to find tests that should be considered when creating the smoke test suite. The table shows each test's name, code location, partition, duration, and result. Select the tests you want to include and click Add Selected Tests to add them to the optimization set.
The Coverage Treemap and the Relative Coverage over Time chart update to reflect the currently selected tests. The Test Budget slider lets you set a time constraint for the suite.
Prioritizing Tests
Switch to the Prioritize Tests tab to optimize the selected test set. Click Perform Pareto Ranking to compute the optimal ordering of tests—the ranking maximizes code coverage for any given time budget.
Available actions:
- Remove Selected Tests: Remove tests from the current set.
- Download CSV: Export the ranked test list.
- Save List: Save the current test selection under a name for later reuse.
- Load List: Restore a previously saved test list.
Tests that exceed the configured time budget are visually de-emphasized in the table.
