Files
error-prone-support/refaster-test-support
Rick Ossendrijver f3571f13dd Introduce documentation generation
This is a squash commit of the following previous commits:

---

Introduce `documentation-support` module to extract website data from source code

By adding a compilation `TaskListener` that extracts data from the Bug pattern
and Refaster rule collection (test) classes and writing to JSON output files
in the target directory. This extraction happens as part of the Maven build
using the `docgen` profile.

---

Improve website styling

Co-authored-by: japborst <japborst@gmail.com>
Co-authored-by: Gijs de Jong <berichtaangijs@gmail.com>

---

Generate Markdown files from existing content for the website

---

Upgrade dependencies to the latest versions

---

Compile and install project jars before docgen

---

Run validation in build and exclude self-url

---

Reintroduce `htmlproofer`, improve templates, cleanup setup and dependencies

---

Delete directory if it exists

---

Add SCSS for GitHub button and fix bug pattern sample rendering

---

Fix bug pattern GitHub link

---

Small styling tweaks (incl. for dark theme)

---

Use single mvn command

---

Move mustache templates

---

Hardcode anchors for headings

---

Add supression to bugpatterns

---

Remove self ignore for html-proofer

---

Add refaster supressions and use callouts

---

Use v0.4.1-SNAPSHOT

---

Revert "Use single mvn command"

This reverts commit 594471d1ed23a1c19d7fe88d925d1b7f828716cd.

---

Extract Refaster samples from source code instead of AST

---

Skip verification, for now

---

Add notes on disabling bugpatterns

---

Set default layout and image

---

Fix mobile navigation

---

Revert "Set default layout and image"

This reverts commit 67a4aa7b5b4d14c0f2b783f345f53affe6ef3ec5.

---

Add supression for refaster rules

---

Post-rebase fixes

---

Fix the tests

---

Doh

---

Version bump

---

Exclude ThirdPartyLibraryTest from Bug Pattern test output

---

Remove only last occurence of 'Test' in Bug Pattern tests doc generation

---

Move `MapRulesTest` resources

---

Add exclusion for docgen of `SourceCodeTest`

---

Bump version

---

Extra fixes after rebase

---

Delete custom nav footer and `assets/images/favicon.ico`

---

Post rebase fixes with version bump to `0.8.1-SNAPSHOT`

---

Use new BugPatternTest extraction method
2023-10-21 13:20:47 +02:00
..
2023-10-21 13:20:47 +02:00

Refaster test support

This module provides utilities to validate Refaster rule collections. A rule collection is a set of Refaster rules represented as static nested classes, all located in a shared top-level class.

What does this module do?

These utilities allow for validating the rewrites (or absence of rewrites) performed by Refaster rules. Each collection of Refaster rules defined in a single top-level class is applied to an input file, and the resulting rewrites should match the associated output file.

The validation performed by this module ensures that each Refaster rule is tested, making sure that it matches and transforms code as intended. If a Refaster rule is not covered by a test, if it influences unrelated test code, or if the associated test doesn't follow certain established standards, then this irregularity will be reported, and the associated rule collection test will fail. This way, developers receive guidance on how to write Refaster rule tests and assurance that every rule is properly tested.

How to test a collection of Refaster rules

In a nutshell, to test a Refaster rule collection using the RefasterRuleCollection class, one should create suitably named input and output source code files. The collection's Refaster rules are applied to the input file, and the generated patches must exactly produce the contents of the associated output file.

To test Refaster rules, one can create a (parameterized) test for every class that contains Refaster rules and invoke RefasterRuleCollection#validate. This test utility applies the Refaster rules in the collection to a provided input file, and expects the result to exactly match the contents of a provided output file.

To adopt this setup, the following requirements must be met:

  • Each Refaster rule collection must match the naming convention <RuleCollectionName>Rules.java.
  • There is a test class with a (parameterized) test method that invokes RefasterRuleCollection#validate on the rule collection(s) to be validated.
  • For every rule collection there is an input file matching the naming convention <RuleCollectionName>RulesTestInput.java.
  • For every rule collection there is an output file matching the naming convention <RuleCollectionName>RulesTestOutput.java.
  • For every Refaster rule in a collection, the associated input and output files must contain a method that validates the rules' behavior. The name of this method must be derived from the name of the Refaster rule it aims to validate, prefixed with test (i.e. test<RefasterRuleClassName>).
  • Each such method contains at least one expression that matches the @BeforeTemplate of the corresponding Refaster rule. As a result, the output file must contain the same method with an updated expression, in accordance with the associated @AfterTemplate.
  • Such methods must not match any other Refaster rules.

An example directory structure for such a setup is as follows:

src/
  main/
    java/
      tech.picnic.errorprone.refasterrules
      └── ExampleRules.java  -- Contains multiple Refaster rules.
          └── Example1Rule
          └── Example2Rule
  test/
    java/
      tech.picnic.errorprone.refasterrules
      └── RefasterCollectionTest.java
             -- This test class invokes
             -- `RefasterRuleCollection#validate`.
    resources/
      tech.picnic.errorprone.refasterrules
      └── ExampleRulesTestInput.java
             -- Contains a class named `ExampleRulesTest` and
             -- two methods named `testExample1Rule` and
             -- `testExample2Rule`.
      └── ExampleRulesTestOutput.java
             -- Contains a class named `ExampleRulesTest` and
             -- two methods named `testExample1Rule` and
             -- `testExample2Rule`.