{"id":19768200,"url":"https://github.com/squareslab/darjeeling","last_synced_at":"2025-04-28T16:10:42.939Z","repository":{"id":28077650,"uuid":"114196348","full_name":"squaresLab/Darjeeling","owner":"squaresLab","description":"Language-independent, search-based program repair -- just your cup of tea! ☕","archived":false,"fork":false,"pushed_at":"2024-07-09T19:59:46.000Z","size":834,"stargazers_count":28,"open_issues_count":72,"forks_count":10,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-01-05T16:13:16.389Z","etag":null,"topics":["bug","bugzoo","defect","genetic","genprog","program","repair","search"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/squaresLab.png","metadata":{"files":{"readme":"README.rst","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-12-14T03:11:46.000Z","updated_at":"2024-07-09T19:59:49.000Z","dependencies_parsed_at":"2023-01-14T08:05:16.985Z","dependency_job_id":"ea11919e-13bc-4757-a9da-06f848844546","html_url":"https://github.com/squaresLab/Darjeeling","commit_stats":{"total_commits":509,"total_committers":4,"mean_commits":127.25,"dds":0.007858546168958758,"last_synced_commit":"e2b48f5bd72b0c42282128ef9216e04bbee0dd50"},"previous_names":[],"tags_count":29,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/squaresLab%2FDarjeeling","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/squaresLab%2FDarjeeling/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/squaresLab%2FDarjeeling/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/squaresLab%2FDarjeeling/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/squaresLab","download_url":"https://codeload.github.com/squaresLab/Darjeeling/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":233231406,"owners_count":18645054,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["bug","bugzoo","defect","genetic","genprog","program","repair","search"],"created_at":"2024-11-12T04:36:08.654Z","updated_at":"2025-01-09T17:38:37.322Z","avatar_url":"https://github.com/squaresLab.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"Darjeeling\n==========\n\nDarjeeling is a language-agnostic search-based program repair tool.\nUnlike other repair tools, such as GenProg, SPR, and Nopol, Darjeeling\ndelegates the responsibility of generating patches, obtaining coverage,\nanalyzing code, and executing tests to other services.\nOnce those auxillary concerns are removed, what is left is a lightweight\nframework for composing and executing repair algorithms: Darjeeling.\n\n\nFeatures\n--------\n\n* *Language Agnostic:* delegates syntax transformation and static analysis to\n  other services.\n* *Containerization:* uses `Docker \u003chttps://www.docker.com/\u003e`_\n  to quickly and safely evaluate patches without executing arbitrary code on\n  your machine.\n* *Custom Repair Templates:* uses\n  `Rooibos \u003chttps://github.com/squaresLab/Rooibos\u003e`_ to support rich, custom\n  repair templates for arbitrary languages.\n* *Asynchronous Evaluation:* accelerates patch evaluation by spreading the\n  load across multiple threads.\n* *Test Redundancy Checking:* uses coverage information to skip test\n  executions that can't be affected by a given patch.\n* *Test Ordering:* numerous test ordering schemes reduce the\n  cost of patch evaluation by prioritizing likely failing tests.\n* *Equivalent Patch Detection:* uses static analysis to\n  `remove duplicate transformations \u003chttps://squareslab.github.io/papers-repo/pdfs/weimer-ase2013-preprint.pdf\u003e`_\n  from the search space.\n\n\nInstallation\n------------\n\nPrerequisites\n.............\n\nTo use Darjeeling,\n`Docker \u003chttps://docs.docker.com/install/linux/docker-ce/ubuntu\u003e`_ must be\ninstalled on your machine, and your user account must be a member of the\n:code:`docker` group in order `to avoid problems related to insufficient privileges \u003chttps://docs.docker.com/install/linux/linux-postinstall\u003e`_\n.\nPython 3.9 or greater and `pip3 \u003chttps://pip.pypa.io/en/stable/installing\u003e`_ must also be installed; Darjeeling will not work with older versions of Python 3 nor will it work with any versions of Python 2.\n\nOptional Extras\n...............\n\nWe strongly recommend that you use `pipenv \u003chttps://pipenv.readthedocs.io/en/latest\u003e`_ to contain your installation of Darjeeling and avoid conflicting with system packages. To install pipenv, execute the following command:\n\n.. code::\n\n   $ pip install pipenv\n\nDarjeeling\n..........\n\nTo install Darjeeling from source via pipenv, execute the following from the root of the repository:\n\n.. code::\n\n  $ pipenv install\n\n\nUsage\n-----\n\nAfter installing Darjeeling via pipenv as shown above, you can drop into the newly created virtual environment by executing the following command from the root of the repository:\n\n.. code::\n\n  $ pipenv shell\n\nTo exit from the virtual environment, you can execute the following command:\n\n.. code::\n\n  (Darjeeling) $ exit\n\nDarjeeling exposes a command-line interface (CLI) for performing program\nrepair, as demonstrated below. The CLI provides a single command, `repair`,\nwhich accepts the path to a Darjeeling configuration file format, described\nbelow.\n\n.. code::\n\n   $ darjeeling repair my-config.yml\n\n\nConfiguration File Format (v1.0)\n--------------------------------\n\nThe Darjeeling configuration file format is written in YAML. Below is an\nexample of a configuration file. The configuration file itself can be\nfound in the `example/gcd \u003cexample/gcd\u003e`_ directory.\n\n.. code:: yaml\n\n   version: '1.0'\n   seed: 0\n   threads: 16\n\n   # provides information about the program under repair, including\n   # the name of the Docker image that is used to provide it, the\n   # location of the source code for the program within that image,\n   # and instructions for building and testing it.\n   program:\n     image: darjeeling/example:gcd\n     language: c\n     source-directory: /experiment/source\n     build-instructions:\n       time-limit: 10\n       steps:\n         - gcc gcd.c -o gcd\n       steps-for-coverage:\n         - gcc gcd.c -o gcd --coverage\n     tests:\n       type: genprog\n       workdir: /experiment\n       number-of-failing-tests: 1\n       number-of-passing-tests: 10\n       time-limit: 5\n\n   # specifies the method/tool that should be used to obtain coverage for\n   # the program.\n   coverage:\n     method:\n       type: gcov\n       files-to-instrument:\n         - gcd.c\n\n   localization:\n     type: spectrum\n     metric: tarantula\n\n   algorithm:\n     type: exhaustive\n\n   transformations:\n     schemas:\n       - type: delete-statement\n       - type: replace-statement\n       - type: append-statement\n\n   optimizations:\n     ignore-equivalent-insertions: yes\n     ignore-dead-code: yes\n     ignore-string-equivalent-snippets: yes\n\n   # places a limit on the resources (e.g., wall-clock time, test executions,\n   # candidate patches) that may be consumed during the search for a repair.\n   resource-limits:\n     candidates: 100\n\n\nBelow, we describe the top-level options exposed by the configuration file:\n\n* :code:`version`: the version of the Darjeeling configuration file format\n  that was used to write the file.\n* :code:`seed`: a seed for the random number generator.\n* :code:`threads`: number of threads over which the repair workload should be\n  distributed.\n\n:code:`program`\n...............\n\nThe :code:`program` section is used to provide essential details about the\nprogram that should be repaired. This section contains the following\nproperties:\n\n* :code:`image`: the name of the Docker image that provides the program\n  under repair.\n* :code:`source-directory`: the absolute path of the source code for the program\n  within the provided Docker image.\n* :code:`language`: the language used by the program under repair. Note that,\n  although Darjeeling supports multiple languages, it is not currently possible\n  to fix bugs that involve more than one language.\n* :code:`build-instructions`: executable instructions for (re-)building the\n  program inside the container. Discussed below.\n* :code:`tests`: details of the test suite used by the program. Discussed below.\n\n:code:`program.language`\n~~~~~~~~~~~~~~~~~~~~~~~~\n\nBelow is a list of the languages that are fully supported by Darjeeling.\nDarjeeling can automatically perform static analysis and compute coverage\ninformation for each of these languages.\n\n* *C:* :code:`c`\n* *C++:* :code:`cpp`\n* *Python:* :code:`python`\n\nThe :code:`text` option (i.e., `language: text`) may be used to ignore the language\nof the program under repair and to treat each file as a text file. When this\noption is used, users will need to manually provide coverage information, and\nstatic analysis will not be performed.\n\n:code:`program.build-instructions`\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThis section provides instructions to Darjeeling for re-building the program\nfor purposes of (a) evaluating candidate patches, and (b) instrumenting the\nprogram for coverage collection. Below is an except of the\n:code:`build-instructions` section from the example above.\n\n.. code:: yaml\n\n   build-instructions:\n      time-limit: 10\n      steps:\n        - gcc gcd.c -o gcd\n      steps-for-coverage:\n        - gcc gcd.c -o gcd --coverage\n\n\nThe :code:`time-limit` specifies the maximum number of seconds that Darjeeling\nshould wait before cancelling a build attempt. The :code:`steps` property\nprovides a sequence of shell commands that are used to build the program\nfor the purpose of patch evaluation. Similarly, the :code:`steps-for-coverage`\nproperty gives a sequence of shell commands that are used to build the\nprogram with coverage instrumentation.\n\n\n:code:`program.tests`\n~~~~~~~~~~~~~~~~~~~~~\n\nThis section is used to describe the test suite used by the program.\nDarjeeling uses the program's test suite to determine the correctness\nof patches and to find acceptable patches that pass all tests.\nDarjeeling offers a number of test suite options out of the box,\nspecified by the :code:`type` property within the :code:`tests`\nsection. We describe these below.\n\n:code:`program.tests[type:genprog]`\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThis type of test suite provides convenient support for GenProg-style test\nscripts used by benchmarks such as ManyBugs, IntroClass, and the GenProg TSE\n2012 benchmarks. GenProg-style test scripts accept a single argument specifying\nthe name of the positive or negative test case that should be executed.\nPositive tests correspond to tests that pass on the original, unmodified\nprogram, whereas negative tests correpond to tests that fail on the original\nprogram. The positive tests are named using the form :code:`p{k}`, where\n:code:`{k}` is replaced by the number of the positive test (starting from 1).\nSimilarly, negative tests are named :code:`n{k}`, where :code:`{k}` is replaced\nby the number of the negative test (starting from 1).\n\nBelow is an example of a :code:`genprog` test suite:\n\n.. code:: yaml\n\n     tests:\n       type: genprog\n       workdir: /experiment\n       number-of-failing-tests: 1\n       number-of-passing-tests: 10\n       time-limit: 5\n\n\nThe :code:`time-limit` property specifies the maximum number of seconds that may elapse\nbefore a test execution is aborted and declared a failure. The\n:code:`number-of-passing-tests` and :code:`number-of-failing-tests`\nproperties state the number of passing and failing tests.\nThe :code:`workdir` property gives the absolute path of the directory\nthat contains the :code:`test.sh` for the test harness.\n\n:code:`program.tests[type:pytest]`\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThis test suite is used by Python programs that support the popular\n`pytest \u003chttps://docs.pytest.org/en/stable/\u003e`_ framework. Note that\npytest can run `unittest \u003chttps://docs.pytest.org/en/stable/unittest.html#unittest\u003e`_\nand `nose \u003chttps://docs.pytest.org/en/stable/nose.html#noseintegration\u003e`_\ntests natively.\n\nBelow is an except from a configuration file that uses :code:`pytest`:\n\n.. code:: yaml\n\n  tests:\n    type: pytest\n    workdir: /opt/flask\n    tests:\n      - tests/test_config.py::test_get_namespace\n      - tests/test_config.py::test_config_from_pyfile\n      - tests/test_config.py::test_config_from_object\n\nThe :code:`workdir` directory specifies the location at which :code:`pytest`\nshould be executed. The :code:`tests` property gives a list of the names of\nthe individual tests belonging to the test suite. Each name is given the\nformat expected by pytest. That is, the name of the file containing the\ntest (relative to :code:`workdir`), followed by :code:`::` and the name\nof the test method.\n**Note that automated discovery of test cases is not currently\nimplemented, but is planned for a future release.**\n\n\n:code:`coverage`\n................\n\nThe :code:`coverage` section provides Darjeeling with instructions for computing\ntest coverage for the program under repair. Below, we describe the properties\ncontained within this section:\n\n* :code:`method`: the tool that should be used to compute coverage for the program\n  under repair. This information is necessary since Darjeeling deals with multiple\n  languages, and each languages may have more than one associated tool for\n  obtaining coverage. Out of the box, Darjeeling provides support for :code:`gcov`,\n  used for C and C++ programs, and :code:`pycoverage`, used for Python programs.\n  Support for additional coverage methods may be added via Darjeeling's plugin\n  mechanism.\n  Further details on these two methods are provided below.\n* :code:`load-from-file`: optionally specifies the location of a file from which\n  coverage should be read. An example of such a coverage file can be found in\n  `example/flask/coverage.yml \u003cexample/flask/coverage.yml\u003e`_.\n* :code:`restrict-to-files`: optionally gives a list of files to which the\n  coverage collection should be restricted to. Files should be given as paths\n  relative to the specified :code:`source-directory` for the program.\n  Coverage that is generated for files outside of this set will be automatically\n  discarded by Darjeeling. Note that this property uses the same format as\n  :code:`localization.restrict-to-files`.\n* :code:`restrict-to-lines`: optionally gives a list of lines that the coverage\n  coverage collection should be restricted to. Lines outside of this set will be\n  automatically ignored.\n  This method uses the same format as :code:`localization.restrict-to-lines`,\n  shown below.\n\n\n:code:`gcov`\n~~~~~~~~~~~~\n\nBelow is an excerpt from an example configuration that uses :code:`gcov` for\ncoverage collection.\n\n.. code:: yaml\n\n   coverage:\n     method:\n       type: gcov\n       files-to-instrument:\n         - gcd.c\n\n\nThis method accepts a single, optional property, :code:`files-to-instrument`.\n**This property is very important.**\nBy default, programs compiled with the appropriate :code:`--coverage` option\nset in their :code:`CFLAGS`, :code:`CXXFLAGS`, and :code:`LDFLAGS` will produce\n:code:`.gcda` files at runtime. The gcov tool computes coverage by reading both\nthose :code:`.gcda` files and their associated :code:`.gcno` files, generated\nduring compilation. More specifically, programs compiled with the :code:`--coverage`\noption will write coverage data to disk during the *normal termination* of the\nprogram (i.e., the program exits with code zero). If the program abruptly\nterminates (e.g., due to memory corruption), :code:`.gcda` files will NOT be\nproduced.\n\nThis behavior is problematic for Darjeeling. It prevents collection from being\nobtained for failing tests that crash the program. As a workaround, Darjeeling\nadds source-based instrumentation to the program (in the form of a signal\nhandler) that causes the program to (attempt to) flush its coverage information\nin thee event of abrupt termination. The :code:`files-to-instrument` property\ngives the names of the source code files that provide entrypoints to the program\nbinaries (i.e., :code:`main` functions).\n\n\n:code:`localization`\n....................\n\nThe :code:`localization` section provides instructions for localizing the fault\ninside the program under repair. Currently, the configuration file\nformat supports a single :code:`type` of fault localization: spectrum-based fault\nlocalization, which assigns a suspiciousness value to each line in\nthe program under repair based on the number of passing and failing tests\nthat touch that line. A *suspiciousness metric* is used to compute\nindividual suspiciousness values. The configuration file exposes a number of\nmetrics via its :code:`metric` property:\n\n* :code:`tarantula`\n* :code:`genprog`\n* :code:`jaccard`\n* :code:`ochiai`\n\nThe :code:`localization` section also exposes an :code:`exclude-files`\nproperty, which may be used to exclude certain files from the fault\nlocalization. Each file should be given by its location relative to the source\ndirectory for the program under repair.\nIn the example below, the files :code:`foo.c` and :code:`bar.c` are excluded\nfrom the fault localization.\n\n.. code:: yaml\n\n   exclude-files:\n     - foo.c\n     - bar.c\n\nIndividual source code lines can also be excluded using the :code:`exclude-lines`\nproperty, as shown below. The :code:`exclude-lines` property states which lines should\nbe excluded from specified files. In the example below, lines 1, 2, 3 and 4 from\n:code:`foo.c`, and lines 4, 6, 7 from :code:`bar.c` are excluded from the fault\nlocalization.\n\n.. code:: yaml\n\n   exclude-lines:\n     foo.c: [1, 2, 3, 4]\n     bar.c: [4, 6, 7]\n\nThe fault localization can also be restricted to only consider certain files\nby using the :code:`restrict-to-files` property, as shown below.\n\n.. code:: yaml\n\n   restrict-to-files:\n     - foo.c\n\nSimilarly, the fault localization can also be restricted to individual source\ncode lines using the :code:`restrict-to-lines` property:\n\n.. code:: yaml\n\n   restrict-to-lines:\n     foo.c: [11, 14, 16]\n\n\n:code:`algorithm`\n.................\n\nThe :code:`algorithm` section outlines the search algorithm that should be used\nto search the space of candidate repairs. A description of the types of\nsearch algorithm exposed by the configuration file format is given below.\n\n* :code:`exhaustive`: iterates over all single-transformation patches within\n  the search space until the termination criteria are met.\n* :code:`genetic`: implements a customisable genetic algorithm, inspired by\n  `GenProg \u003chttps://squareslab.github.io/genprog-code\u003e`_.\n\n\n:code:`transformations`\n.......................\n\nThe :code:`transformations` section describes the space of program\ntransformations from which candidate patches should be composed. The\n:code:`schemas` property of this section specifies a list of the program\ntransformation schemas, along with any parameter values for those schemas, that\nshould may be used to construct concrete program transformations. Each entry in\nthe :code:`schemas` list must specify a :code:`type`.\n\nThe configuration format supports three \"classical\" statement-based\ntransformation schemas based on those introduced by\n`GenProg \u003chttps://squareslab.github.io/genprog-code\u003e`_:\n:code:`delete-statement`, :code:`replace-statement`, and :code:`prepend-statement`;\n:code:`swap-statement` has not been implemented at the time of writing.\nTo learn more about why Darjeeling uses :code:`prepend-statement` rather than the\ntraditional :code:`append-statement` schema, see the\n`Darjeeling design document \u003cdocs/design.md\u003e`_.\nBelow is an example of :code:`schemas` property that uses all of the classical\nstatement-based schemas.\n\n.. code:: yaml\n\n   schemas:\n     - type: delete-statement\n     - type: replace-statement\n     - type: prepend-statement\n\nThe configuration format also supports custom repair templates via\nmatch-rewrite patterns for `Rooibos \u003chttps://github.com/squaresLab/Rooibos\u003e`_.\nBelow is an example of a simple repair template that replaces all calls to\n:code:`foo` with calls to :code:`bar`.\n\n.. code:: yaml\n\n   - type: template\n     match: \"foo(:[1])\"\n     rewrite: \"bar(:[1])\"\n\nThe :code:`type` property is set to :code:`template` to indicate that this schema\nrepresents a Rooibos-based repair template. The :code:`match` and :code:`rewrite`\nsections are used to specify match and rewrite patterns, respectively.\n\nDarjeeling also provides support for naive line-based transformations,\ngiven below, which can be used for programs that use languages that are\nnot fully supported (i.e., programs that use the :code:`text` language).\n\n.. code:: yaml\n\n   - type: delete-line\n   - type: insert-line\n   - type: replace-line\n\n\n:code:`optimizations`\n.....................\n\nThe :code:`optimizations` section is used to toggle various optimizations available\nto the repair process. By default, all optimizations are enabled. Below is a\nlist of optimizations that can be toggled by the configuration file.\n\n* :code:`use-scope-checking`: ensures that all variable and function references\n  that occur in a given transformation are visible from the scope into\n  which they are being inserted.\n* :code:`use-syntax-scope-checking`: ensures that any keywords introduced by a\n  transformation (e.g., :code:`break` and :code:`continue`) are permitted by their\n  surrounding context.\n* :code:`ignore-dead-code`: prevents the insertion of code that exclusively\n  writes to dead variables.\n* :code:`ignore-equivalent-insertions`: uses an approach inspired by\n  instruction scheduling to prevent equivalent insertions of code.\n* :code:`ignore-untyped-returns`: prevents insertion of a :code:`return` statement into\n  a context where the type of the retval is incompatible with the return type\n  of the enclosing method or function.\n* :code:`ignore-string-equivalent-snippets`: transforms donor code snippets into\n  their canonical form, thus preventing the insertion of string-equivalent\n  snippets.\n* :code:`ignore-decls`: prevents transformations that are either applied to declaration\n  statements, or else solely introduce a declaration statement.\n* :code:`only-insert-executed-code`: prevents the insertion of code that has not been\n  executed by at least one test case.\n\n\n:code:`resource-limits`\n.......................\n\nThe :code:`resource-limits` section of the configuration file is used to impose\nlimits on the resources that may be consumed during the search. The search will\nbe terminated upon hitting any of these limits. The limits specified in this\nsection of the configuration file may be overridden by command-line options. If\na limit for a particular resource is not given in either the configuration file\nor as a command-line argument, then the use of that resource will be unbounded\n(i.e., no limit will be imposed).\n\nBelow is a list of the resource limits that may be specified in the\nconfiguration file:\n\n* :code:`candidates`: the maximum number of candidate patches that may be evaluated.\n  May be overriden at the command line by the :code:`--max-candidates` option.\n* :code:`time-minutes`: the maximum length of wall-clock time that may be spent\n  searching for a patch, given in minutes.\n  May be overriden at the command line by the :code:`--max-time-mins` option.\n\n\nSearch Algorithms\n-----------------\n\nThis section describes the different search algorithms that are supported by\nDarjeeling.\n\n\n:code:`exhaustive`\n..................\n\nThe :code:`exhaustive` search algorithm exhaustively searches over all legal\nsingle-transformation patches within the search space until the termination\ncriteria are fulfilled.\n\n:code:`genetic`\n...............\n\nThe :code:`genetic` search algorithm implements a genetic algorithm that is inspired\nby the one used by `GenProg \u003chttps://squareslab.github.io/genprog-code\u003e`_, a\nformative search-based program repair tool for C. Below is an excerpt from a\nconfiguration file that uses a :code:`genetic` search algorithm.\n\n.. code:: yaml\n\n   algorithm:\n     type: genetic\n     population: 80\n     generations: 20\n     tournament-size: 3\n     mutation-rate: 0.6\n     crossover-rate: 0.1\n     test-sample-size: 0.4\n\n\nBelow is a list of the parameters that are exposed by :code:`genetic`:\n\n* :code:`population`: the size of the (initial) population. Used to control the\n  number of individuals that are selected as parents.\n* :code:`generations`: the maximum number of generations.\n* :code:`tournament-size`: the size of the tournament when performing tournament\n  selection to choose parents. Larger tournament sizes lead to an increased\n  selective pressure.\n* :code:`mutation-rate`: the probability of an individual mutation event.\n* :code:`crossover-rate`: the probability of an individual crossover event between\n  two parents.\n* :code:`test-sample-size`: controls test sampling. When test sampling is\n  enabled, the fitness of an individual is computed using a randomly selected\n  subset of the test suite, rather than the entire test suite. (More specifically,\n  test sampling selects a subset of the passing tests whilst keeping all of the\n  failing tests.)\n  The value of :code:`test-sample-size` is used to specify the size of the subset\n  (or *sample*). If :code:`test-sample-size` is given as a float, then it will be\n  treated as a fraction. If :code:`test-sample-size` is given as an integer, then its\n  value will be used as the absolute number of (passing) tests that should be\n  included in the sample. If :code:`test-sample-size` is omitted or set to\n  :code:`null`, test sampling will be disabled.\n\n\nExtending Darjeeling via Plugins\n--------------------------------\n\nUsers may extend Darjeeling's capabilities with their own plugins.\nUpon launch, Darjeeling will find and automatically import all installed\nPython packages whose name starts with :code:`darjeeling_` (e.g.,\n:code:`darjeeling_ardupilot`).\n\nDarjeeling treats the following features as framework extension points,\nallowing variants to be added by plugins:\n\n* Search algorithms\n* Transformation schemas\n* Test harnesses\n* Coverage tools (e.g., :code:`jacoco`, :code:`pycoverage`, :code:`sancov`)\n* Spectrum-based fault localisation suspiciousness metrics\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsquareslab%2Fdarjeeling","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsquareslab%2Fdarjeeling","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsquareslab%2Fdarjeeling/lists"}