Sample questions
Sd Ci Test InfrastructureDifficulty 1
What is the main goal of distributing a test suite across multiple parallel workers (test sharding)?
- aTo make every individual test case use less CPU memory than before
- bTo rewrite tests into fewer, larger test files so the codebase is easier to browse through
- cTo divide the suite into subsets that execute simultaneously on different machines✓
- dTo automatically detect and remove duplicate assertions from the suite
Explanation:Test sharding splits a large suite into smaller subsets that run in parallel on separate workers/machines; because they execute concurrently instead of sequentially, the total wall-clock time to finish the whole suite drops, even though total CPU time stays roughly the same.
Sd Ci Test InfrastructureDifficulty 1
A test suite is split into 4 shards simply by dividing the test files into 4 equal-sized groups by file count. What is the main risk of this approach?
- aSome shards may end up with far more total execution time, bounding the whole run✓
- bThe test suite will report false positives for every test in the slowest shard
- cEqual-count sharding always exceeds the maximum number of allowed parallel workers
- dSplitting by count causes test files to be corrupted during the copy step
Explanation:Test files rarely take the same amount of time to run. Splitting purely by count can leave one shard with several long-running tests while another finishes quickly, so overall wall-clock time is still dictated by whichever shard finishes last.
Sd Ci Test InfrastructureDifficulty 2
Compared to splitting a suite purely by test count, which approach better balances the total wall-clock duration of each shard?
- aAssigning tests to shards in alphabetical order of their file names
- bAssigning tests to a new random shard on every single run
- cAssigning tests to shards based on the file size in bytes of the test source code, assuming larger files take longer to run
- dAssigning tests using historical execution-duration data collected from previous runs✓
Explanation:Using recorded execution durations from previous runs lets the scheduler pack tests so each shard's summed duration is close to equal, which balances wall-clock time far better than count-based, alphabetical, random, or file-size-based assignment, none of which correlate reliably with actual runtime.
Sd Ci Test InfrastructureDifficulty 1
In the context of distributed test execution, what does 'makespan' refer to?
- aThe total number of individual test cases across all shards combined
- bThe time taken until the last-finishing shard completes✓
- cThe average CPU utilization percentage recorded across all worker machines
- dThe number of test files that were skipped due to missing dependencies
Explanation:Makespan is the completion time of the last shard to finish; because shards run in parallel, the overall run is only as fast as its slowest shard, so minimizing makespan (not simply equalizing test counts) is the real optimization goal of a sharding algorithm.
Sd Ci Test InfrastructureDifficulty 2
In a duration-based test sharding system, how is a brand-new test with no prior execution history typically handled?
- aIt is permanently excluded from shard assignment until a human manually assigns it
- bIt gets an estimated duration, such as the mean of existing tests, until real data builds up✓
- cIt is always placed alone in its own dedicated shard regardless of suite size
- dIt is executed twice in the same run to generate history before the actual sharding decision is made
Explanation:Since there is no timing data for a new test yet, most duration-based schedulers fall back to a default estimate (often the suite average or a configured default) so the test can still be packed into a shard sensibly; real data then accumulates for future runs.
Sd Ci Test InfrastructureDifficulty 2
A test-sharding scheduler sorts all tests by descending expected duration, then repeatedly assigns the next test to whichever shard currently has the smallest accumulated total duration. Which scheduling strategy does this describe?
- aFirst-in-first-out (FIFO) queueing
- bBinary search over the sorted test list
- cDepth-first traversal of the test dependency graph
- dGreedy longest-processing-time-first bin packing✓
Explanation:Sorting by descending duration and always assigning the next item to the least-loaded bin is the classic greedy 'longest processing time first' (LPT) heuristic for bin-packing/scheduling problems; it is a simple, effective way to balance shard durations without needing an optimal, much more expensive solution.