Support adding and testing new rules without using Xcode (#2065)

Author: calda

.github/workflows/build.yml

@@ -9,10 +9,9 @@ jobs:
       fail-fast: false
       matrix:
         macos:
-          - 13
-          - latest
+          - 15
         xcode:
-          - latest-stable
+          - 16.3
     runs-on: macos-${{ matrix.macos }}
     steps:
       - name: Select Xcode version
@@ -91,9 +90,9 @@ jobs:
       fail-fast: false
       matrix:
         macos:
-          - 13
+          - 15
         xcode:
-          - latest-stable
+          - 16.3
     runs-on: macos-${{ matrix.macos }}
     steps:
       - name: Select Xcode version
@@ -110,9 +109,9 @@ jobs:
       fail-fast: false
       matrix:
         macos:
-          - 13
+          - 15
         xcode:
-          - latest-stable
+          - 16.3
     runs-on: macos-${{ matrix.macos }}
     steps:
       - name: Select Xcode version
@@ -129,9 +128,9 @@ jobs:
       fail-fast: false
       matrix:
         macos:
-          - 13
+          - 15
         xcode:
-          - latest-stable
+          - 16.3
     runs-on: macos-${{ matrix.macos }}
     steps:
       - name: Select Xcode version

CONTRIBUTING.md

@@ -65,6 +65,26 @@ Tests are run automatically on all pull requests, branches and tags. These are t
 
 There is a separate Performance Tests scheme that you should run manually if your code changes are likely to affect performance.
 
+Test cases for individual rules can be ran via the command line using the `./Scripts/test_rule.sh` script. For example:
+
+```sh
+$ ./Scripts/test_rule.sh blankLinesAtStartOfScope
+$ ./Scripts/test_rule.sh indent
+$ ./Scripts/test_rule.sh wrap
+```
+
+## Tips
+
+* Use existing helpers in `ParsingHelpers.swift` or `FormattingHelpers.swift` where possible. There are existing parsing helpers for many parts of the Swift grammar, like: 
+  * Types (`parseType(at:)`) 
+  * Declarations (`parseDeclarations()`)
+  * Expressions (`parseExpressionRange(startingAt:)`)
+  * Properties (`parsePropertyDeclaration(atIntroducerIndex:)`)
+  * Functions (`parseFunctionDeclaration(keywordIndex:)`)
+  
+* Define helpers in extensions on `Formatter` at the bottom of the Rule file. These should be `internal` to improve discoverability. Helpers used by multiple rules should be moved to `ParsingHelpers`.
+  * Before writing new parsing helpers, consider checking if any existing rule has parsing helpers that could be reused.
+
 ## Prerelease builds
 
 If you contribute a new rule or option, it would be published in the following major version release. To start using the new rule or option right away in your own project, you could use a prerelease build of the `develop` branch. More information is available [here](https://github.com/nicklockwood/SwiftFormat#prerelease-builds).

Scripts/test_rule.sh

@@ -0,0 +1,33 @@
+#!/bin/bash
+
+# Script for testing individual SwiftFormat rules.
+# $ ./Script/test_rule.sh blankLinesAtStartOfScope
+
+# Argument validation
+if [ "$#" -ne 1 ]; then
+    echo "Usage: $0 <RuleName>" >&2
+    exit 1
+fi
+
+rule_name="$1"
+
+# Capitalize the first letter
+first_char_upper=$(echo ${rule_name:0:1} | tr '[:lower:]' '[:upper:]')
+rest_of_name="${rule_name:1}"
+class_name_stem="${first_char_upper}${rest_of_name}"
+
+# Append "Tests"
+TEST_CLASS_NAME="${class_name_stem}Tests"
+
+# Validate test file existence
+TEST_FILE_PATH="Tests/Rules/${TEST_CLASS_NAME}.swift"
+if [ ! -f "$TEST_FILE_PATH" ]; then
+    echo "Error: Test file ${TEST_FILE_PATH} not found." >&2
+    exit 2
+fi
+
+echo "Testing ${rule_name} rule..."
+
+# Run tests for the specific rule using swift test
+SWIFT_TEST_TARGET="SwiftFormatTests"
+swift test --filter "${SWIFT_TEST_TARGET}.${TEST_CLASS_NAME}" 2>&1