Design decisions

General considerations

  • Programming paradigms
  • Principles

Command line interface

`Click`_ is used to implement the Command Line Interface (CLI). Refer to Why click? and the Why not (…)? sections for more information about the differences in comparison to other CLI specific packages.

Configuration file

As configuration file format (semantic mapping, etc.) StrictYAML is used. StrictYAML is a type-safe subset of YAML which enables advantages and avoids disadvantages of YAML. Refer to Why StrictYaml? for more information about the advantages of StrictYAML compared to other configuration file formats. StrictYaml is used to parse and validate configuration file input.

Detection of changes

Changes of the production and test code will be determined on different levels of abstraction.

Detection of file scope changes

W.r.t. file scope state changes (file added/modified/deleted) the approach will differ dependent on the runtime environment (local devemlopment machine - local, CI server - ci). There are some design choices which are based on the determination of

  • filesystem metadata, e.g. time of last file change
(choice for environment local only)
  • filesystem events (choice for environment local only)
  • checksums over files (choice for environment local as well as ci)
  • version control system (VCS) information (choice for environment local as well as ci)

To support file scope change detection in the ci environment a VCS based approach is used. It is planned to support the version control system git out-fo-the-box. The implementation won’t consider extensibility of VCS support (no plugin system and pre-packaged plugin approach) in the beginning but aims at a plugin system conform API to ease probable later refactoring. (Encapsulating VCS support into externally deployed plugins could potentially ease maintenance over the long run.) If you are interested in contributing support for another VCS like Bazaar, Mercurial, etc. feel free to create pull requests. The VCS functionality should be easily exchangeable using a configuration option and strategy pattern (to exchange VCS implementations).

The capabilities and known limitations of the packages have been analyzed. The following characteristics have been considered during evaluation:

  • dependencies
  • implementation of performance critical logic in C
  • supported OS
  • interface which would allow to implement semantid diffs

VCS (git) based detection of file scope changes

The following alternatives have been considered to implement interaction with the VCS git.

GitPython is used to implement git based file scope change detection.

Semantic diff

Initially it was planned to use packages which provides “semantic diff” capabilities. In comparison to a “file scope diff” a “semantic diff” contains contextual information about the changes of source code files (instead of types of file states and line based differences).

In case of a Python language aware semanitc diff: Instead of beeing able to work with the diff information “file xxx and file yyy was modified” one could work with information like “in file xxx class a method b was modified and module scope function c was moved to file yyy”. This would allow to improve the granularity of the impact map and coverage map significantly. Sadly at time of writing no packages are known which provide the required functionality (reliability, completeness w.r.t. Python language entities) be used for semantic diffs.

The following alternatives have been evaluated to implement granular, semantic determination of (file) changes below the file level with semantic diffs. However no alternative is usable and has not been evaluated in more detail.

Continuous Integration environment

Task execution

tox is used to allow the execution of every CI job in various Python virtual environments.

Testing

Tests of python-tia depend on the test runner pytest (docs). Execution of tests will be integrated into the CI environment via tox environment tests.

Static analysis

Various static analyzers are integrated into the CI environment and are invoked using various tox environments defined in tox.ini.