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

Design

Jump to bottom
An-Nadein edited this page Dec 12, 2019 · 18 revisions
  1. The SCM identifies change scope between two revisions
  2. The engine analyzes bytecode and builds a CDG
  3. Processor finds related, disconnected tests by CDG

SCM

Sandboni-SCM works with Git interface to get Change Scope

  • Finds appropriate RevisionId for 'FROM' and 'TO' constants [LATEST_PUSH, LATEST_COMMIT, LOCAL_CHANGES_NOT_COMMITTED]
  • Calls Git interface command to get Diff Entries list
  • Computes change scope

The Engine

The Engine implements the first Sandboni design principle - Principle of Least Effort- by applying the static JVM byte code analysis without actually executing it. This is an exceptionally efficient way to build a CDG and detect change-related tests. Consequently, for a low penalty in time and compute resources, we can execute the Sandboni filter just-in-time and every time we derive a change code coverage. The stateless engine does not need persistent stores, in-memory caches, and extensive synchronizations. This makes our task much easier and we can fully focus on the algorithm's complexities.
Processor Placed at the heart of the engine, its the coordinator between the other parts - every interaction between other components happens through the Processor.
Context Shared information about the CDG
GitInterface The client API to the SCM inspector that we'll cover shortly. Supplies a change set details: what files were changed, change type - add, delete, rename/move, and line numbers
Finder Finders build CDG. A Finder reads byte code or source files and creates incoming and outgoing links between nodes. For byte code files (i.e. *.class), nodes are interfaces, abstract classes, and their implementations, methods, and instance and class variables. Nodes constructed from source files are Cucumber feature and scenario names or HTTP URLs from Selenium tests.
Connector After Finders are done, Connectors enrich the CDG. Most of them create links between the main code and non-JUnit tests that byte code inspection could not identify. Some of them enrich the nodes with commit-level information.
Builder The keeper of CDG - constructs the graph and coordinates all graph's operations

Finders
CucumberFeatureFinder Discovers Cucumber tests and links them to the CDG
ExplicitFinder Following the Precautionary principle, creates links between classes, methods, variables that were manually described.
BcelFinder Builds the CDG and while doing so, links all tests that have been implemented by JUnit. As the name suggests, we leverage BCEL to read byte code and build relationships between entities.
JarFinder Links test classes supplied in jar files on the classpath to the CDG

Connectors
PartContainerConnector Creates a supporting vertex that represents the container (the app) where all other nodes reside. It's used to identify disconnected tests - those that we could not safely identify as not related to the change.
HttpTemplateConnector Adds tests that interact with main code base via HTTP APIs to the CDG
CucumberJavaConnector Adds tests that implement Cucumber features to the CDG
JsonConnector Adds Selenium tests to the CDG. Relies on Seloni pre-processing.
JiraConnector Enriches each node with the Jira ID against which the last node change was made. For ex., if method A was modified 3 times against Jira 1,2,3 in that order, the node that represents the method A will contain metadata that describes Jira 3

Visitors

Finders use visitors to construct a CDG. Visitors seamlessly integrate with BCEL to traverse and analyze the class files contents. Each class visitor delegates work to one or more method visitors. The key class visitors are:
TestClassVisitor Links init/destroy methods annotated with standard JUnit annotations to the CDG
SpringControllerClassVisitor Links methods and variables annotated with Spring annotations
JavaxControllerClassVisitor Links methods and variables annotated with Javax annotations
AffectedClassVisitor Simply delegates class changes to the method visitor
CallerClassVisitor Does most of the work: traverses a byte code and relates line numbers supplied in a git change set to the class methods. Builds links between the modified method and methods/fields the modified method relies on.
ImplementingClassVisitor Links methods in each interface inherited by a class

How the algorithm works?

sandboni block diagram

The above diagram is a high-level overview of the Sandboni architecture

  1. Get change scope, i.e., the files and line numbers that were changed in the specified SCM range.
  2. Analyze bytecode of project to find all relations inside the code
  3. Build a Change Dependency Graph (CDG) based on change scope and bytecode analysis
  4. Find related and disconnected tests by traversing through the CDG
  5. Execute them

Sandboni uses a static analysis of compiled JVM byte-code in order to build the CDG

What is static analysis?

Static analysis, also called static code analysis, is a method of examining the code without executing the program. It allows us to understand the code structure and its internal and external dependencies

Clone this wiki locally