Skip to content

Latest commit

 

History

History
44 lines (27 loc) · 2.91 KB

hackers_guide.md

File metadata and controls

44 lines (27 loc) · 2.91 KB
Raw

General

Pitest supports java bytecode generated by java versions as far back as 5, and execution on java versions from 8 upwards.

Testing against different Java versions is currently largely tied to compilation of the project itself, so the project is built in a matrix via travis. Building the code and testing against different java versions would ideally be seperated form each other, but that's a big job to fix.

It is recommended to use Java 9 while developing - apis and language features past 8 cannot be used. Ideally something like animal sniffer would be used to enforce this while coding in later Java versions, but this has not been setup.

Although the codebase now uses java 7 and 8 language features, for most of its history pitest was compiled using Java 5. Conversion to Java 8 was largely done by automated tooling, so lambda usage may be inconsistent and/or strange.

Structure

Pitest is split into several modules

  • pitest - Main mutation engine and other code that must share a JVM with the system under test
  • pitest-entry - The main entry point for build tools. Contains code that runs in main controller process.
  • pitest-html-report - Generates the html report
  • pitest-command-line - Command line tool for running pitest
  • pitest-maven - Maven mojo for running pitest
  • pitest-ant - Ant task for running pitest
  • pitest-maven-verification - Integration tests that execute pitest via maven module
  • pitest-java8-verification - Integration tests that validate pitest against java 8 features
  • pitest-groovy-verification - Integration tests that validate pitest behaviour with groovy
  • pitest-build-config - A minimal checkstyle configuration used in other modules.

Care must be taken not to load the code under test into the JVM within the pitest-entry module (e.g by the use of reflection).

Third party dependencies must not be introduced into the pitest module as they may conflict with those of the code under test. Where dependencies are unavoidable (e.g ASM) they must be shaded to avoid conflict.

Dependencies may be introduced into the other modules, but are discouraged so start a discussion before doing so. Any dependencies introduced must be added to the classpath by users of the command-line tool and Ant.

Eclipse users

Import everything as an existing maven project. If you do not have groovy plugins installed, the pitest-groovy-verification module will show errors. Unless you are working on something Groovy related it is easiest just to close the module rather than installing the Groovy dependencies into eclipse.

Code format

The files code_format_profile.xml and code_cleanup_profile.xml in the root of the repository.

Will create formatting and cleanup profiles named henry. Some aspects of these will be changed in the future (e.g. the use of columns to layout fields) but they should be used while editing pitest to maintain consistency.

InteliJ

Import everything as an existing maven project.