Skip to content
This repository has been archived by the owner on Dec 14, 2022. It is now read-only.

Home

Jump to bottom
VL edited this page Sep 9, 2019 · 6 revisions

What is Sandboni

Sandboni is a Java test optimization library which reduces test execution time without compromising quality, predicts defect probability and presents actionable test results which allows developers to take preemptive measure

Definitions

  • Change - When we refer to a change, we mean all code parts directly and, most importantly, indirectly affected by the two successive versions in the repository. More formally, we define a change as a set of control flow graphs originated by a set of code modifications
  • Change risk - Change risk is the probability that a change to software will lead to a loss caused by the software failure. The probability takes into account neither the assessment of a potential loss nor the cost of risk management
  • Change Dependency Graph (CDG) - Method and instance and class variables invocations between classes. Takes into consideration different relation types between classes such as method-to-method calls, class-in-method definitions, polymorphic calls and static classes
  • CDG Node - A method, instance or class variable
  • CDG Edge - A call between two methods
  • Change Code coverage - The degree to which the change is executed by running tests

The bottom line

Instead of applying a brute force approach to testing (i.e. execute all tests each time there is a code change), determine the code slice affected by the change and execute tests that are close to the change. Decision is based on the static code analysis that lets us determine required tests without executing them for the price of being less than 100% precise

Design Principles

Principle of Least Effort
Do the least amount of work to detect all change-related tests and coverage. This rule applies to the required amount of computational resources, execution time, design complexity, and functionality

Precautionary principle
When the system is unable to clearly identify a test as unrelated to the change, the system assumes that the test is related

Principle of Frictionless Integration
Design the system as a feature set that adds an ability to perform change-centric testing to the existing IDEs, build tools, SCM systems, and CI pipelines.

Convention over configuration
Minimize the number of decisions a developer is required to make without losing the flexibility. (This typically means that the system should rely on sensible defaults as much as possible, but offer a manual override for every default setting.)

Clone this wiki locally