Selfie JVM Snapshot Garbage Collection is overly zealous when using multiple test suites in gradle
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Domain
- build-system, testing-qa
Research direction
Start with the linked reproducer and its README instructions, then trace Selfie's JUnit5 snapshot garbage-collection logic for separate Gradle test suites. Reproduce the integrationTest run and verify that snapshots under src/test are not deleted when those tests are absent from the integrationTest classpath. Done means unmanaged unit-test snapshots remain intact while stale snapshots are still handled.
Written by the indexing model from the issue text.
Description
In a project I was using a separate integrationTest source set with the JVM Test Suite approach recommended by Gradle link to instructions.
When done this way, the integration test sources will be in src/integrationTest instead of src/test. The classes in src/test will not be on the classpath of the integration tests.
When running Selfie with JUnit5, the current garbage collection logic is hardcoded to only look for *.ss files in src/test/ and performs a Class.forName(...) to see if that test still exists and has tests that match the snapshot. If it doesn't find a match, it deletes the file.
Since the unit tests are invisible on the integrationTest classpath, though, Class.forName(...) throws a ClassNotFoundException so selfie assumes this is a stale file and deletes. As a consequence, all the unit test snapshots are deleted when running the integrationTest task.
Is there some way to get the correct source root from Junit or something like that to avoid deleting unmanaged files?
A reproducer of the described issue can be found here with instructions in the README https://github.com/aelfric/selfie-bug-report-reproducer
- Dominant language
- Kotlin
- Stars
- 101
- Forks
- 18
- Avg merge
- 6d 11h
- Merged PRs (30d)
- 5
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from diffplug/selfie
-
enhancement jvm
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
bug jvm
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
bug docs jvm
Difficulty 2/5 1-3 hours Newbie friendliness 50/100
-
bug jvm py
Difficulty 2/5 1-3 hours Newbie friendliness 48/100
-
bug jvm
Difficulty 4/5 3-5 days Newbie friendliness 38/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
johanhaleby/occurrent#1120 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
2 rename bugs Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
ankidroid/Anki-Android#21999 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
openwallet-foundation/multipaz#2028 ·