You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: AGENTS.md
+17-7Lines changed: 17 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,7 +29,7 @@ While README.md and CONTRIBUTING.md are mainly written for humans, this file is
29
29
30
30
## Build and Development Workflow
31
31
32
-
- When done or preparing to commit changes to java source files, be sure to run `gradlew tidy` to format the code
32
+
- When done or preparing to commit changes to java source files, be sure to run `gradlew tidy` to format the code. Don't bother beforehand.
33
33
- Always run `gradlew check -x test` before declaring a feature done
34
34
35
35
## Code Quality and Best Practices
@@ -38,15 +38,25 @@ While README.md and CONTRIBUTING.md are mainly written for humans, this file is
38
38
- Be careful to not add non-essential logging! If you add slf4j log calls, make sure to wrap debug/trace level calls in `logger.isXxxEnabled()` clause
39
39
- Validate user input. For file paths, always call `myCoreContainer.assertPathAllowed(myPath)` before using
40
40
41
-
## Testing
41
+
## Running Tests
42
+
43
+
- See `dev-docs/gradle-help/tests.txt` for hints on running tests
44
+
- To run a specific test: `gradlew :solr:core:test --tests "org.apache.solr.search.TestCaffeineCache"`
45
+
- To run a specific BATS test: `gradlew iTest --tests test_adminconsole_urls.bats`
46
+
- The randomization seed is important. To repeat a failing tests, pass the same seed given in the failure by adding to Gradle: `-Ptests.seed=HEXADECIMALHERE`.
47
+
- Test output goes to `solr/<module>/build/test-results/test/outputs/OUTPUT-<fully.qualified.TestName>.txt` (stdout/stderr log) and `solr/<module>/build/test-results/test/TEST-<fully.qualified.TestName>.xml` (JUnit XML with pass/fail/error details)
48
+
- To scan test output for a specific issue across already-run tests: `grep -rl "pattern" solr/*/build/test-results/test/outputs/`
49
+
50
+
## Writing Tests
42
51
43
52
- When adding a test to an existing suite/file, keep the same style / design choices
44
53
- When adding a *new* Java test suite/file:
45
-
- Subclass SolrTestCase, or if SolrCloud is needed then SolrCloudTestCase
46
-
- If SolrTestCase and need to embed Solr, use either EmbeddedSolrServerTestRule (doesn't use HTTP) or SolrJettyTestRule if HTTP/Jetty is relevant to what is being tested.
47
-
- Avoid SolrTestCaseJ4 for new tests
48
-
49
-
- See `dev-docs/gradle-help/tests.txt` for hints on running tests
54
+
- Subclass SolrTestCase, or if SolrCloud is needed then SolrCloudTestCase
55
+
- If SolrTestCase and need to embed Solr, use either EmbeddedSolrServerTestRule (doesn't use HTTP) or SolrJettyTestRule if HTTP/Jetty is relevant to what is being tested.
56
+
- Avoid SolrTestCaseJ4 for new tests
57
+
- For BATS shell integration tests in `solr/packaging/test/`:
58
+
- Always use `run <command>` followed by `assert_output --partial "..."` or `refute_output --partial "..."` instead of capturing output into local variables and using `[[ ]]` comparisons
0 commit comments