test: cover annotation lookup when class values cannot be loaded - #3108
test: cover annotation lookup when class values cannot be loaded#3108mvanhorn wants to merge 4 commits into
Conversation
Adds coverage to the existing AnnotationArbitraryClassValueProcessor test for the current behaviour of isAnnotationPresent and getAnnotationsByType on an annotation whose KClass values are not loadable by the processor classloader. Also covers a second annotation that shares the simple name but not the qualified name, which pins the lookup to qualified-name matching. No production code changes; the EXPECTED block records what KSP does today so a later behaviour change shows up as a diff here.
…n-arbitrary-class-value-coverage
|
Hi thanks for the PR. Could you please create an entirely new test and register it in |
Per review, isolate the behavior instead of folding it into annotationWithArbitraryClassValue. Add isAnnotationPresentWithArbitraryClassValue with its own processor and testData, registered in KSPUnitTestSuite with @bug(issues/1038, OPEN) and @TestMetaData, and drop those assertions from the original test.
|
Done. Those assertions are out of Both suites pass locally: |
The test now asserts KSTypeNotPresentException is thrown when accessing the arbitrary class value, and the processor exercises the failing .value.qualifiedName access directly.
|
Good push, the test as written did not demonstrate the failure. It now runs through |
2 participants
Split out from #3092 at @jaschdoc's request, so the test lands before any behaviour change.
Tests only. No production code is touched, and the
EXPECTEDblock records what KSP does today, so a later behaviour change shows up as a diff in this file rather than as new coverage arriving alongside the change.The existing
annotationWithArbitraryClassValuetest covers reading the annotation throughgetAnnotationsByType, where touching aKClassvalue throwsKSTypeNotPresentExceptionbecause the referenced class is not on the processor's classpath. This adds the two things around it that were untested:isAnnotationPresenton that same annotation. The class values still cannot be loaded, so this pins down whether presence is answerable without loading them.ClassValueAnnotationbut not the qualified name. BothgetAnnotationsByType(...).count()andisAnnotationPresent(...)are asserted against it, which pins the lookup to qualified-name matching rather than simple-name matching.Current behaviour, now recorded in
EXPECTED:Verified with:
Both
AAConfiguredUnitTestSuiteandPsiConfiguredUnitTestSuitepass on unmodified upstream code.Related: #1038