Skip to content

Conversation

@misrasaurabh1
Copy link
Contributor

Summary

  • Add Strategy 4 to Java test discovery: import-based matching
  • When a test file imports a class containing the target function, consider it a potential test for that function
  • This fixes an issue where tests like TestQueryBlob (which imports and uses Buffer) were not being discovered as tests for Buffer methods

Problem

When running codeflash on aerospike-client-java, test discovery failed to map tests to functions when:

  • The test class name doesn't follow naming conventions (e.g., TestQueryBlob instead of BufferTest)
  • But the test imports and uses the target class (Buffer)

The previous strategies only matched tests based on:

  1. Test method name containing function name
  2. Direct method calls to the target function
  3. Test class naming convention (CalculatorTestCalculator)

Solution

Add Strategy 4: Import-based matching

  • Extract import declarations from test files
  • If a test imports a class containing the target function, consider it a potential test
  • This catches cases where test names are unrelated to the class name but still exercise the code

Test plan

  • Added test case test_discover_by_import_when_class_name_doesnt_match that reproduces the aerospike-client-java scenario
  • Added test case test_discover_by_direct_method_call for direct calls
  • All existing test discovery tests still pass

🤖 Generated with Claude Code

misrasaurabh1 and others added 3 commits February 2, 2026 23:20
Add Strategy 4 to Java test discovery: import-based matching.
When a test file imports a class containing the target function,
consider it a potential test for that function.

This fixes an issue where tests like TestQueryBlob (which imports
and uses Buffer) were not being discovered as tests for Buffer
methods because the class naming convention didn't match.

Includes test cases that reproduce the real-world scenario from
aerospike-client-java where test class names don't follow the
standard naming pattern.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit adds thorough testing and fixes several bugs discovered
by running test discovery against real-world examples from
aerospike-client-java.

Bugs fixed:
1. Import extraction for wildcard imports (import com.example.*)
   was incorrectly extracting "example" as a class name
2. Static imports (import static Utils.format) were extracting the
   method name instead of the class name
3. *Tests.java files (plural) were not being discovered as test files
4. ClassNameTests pattern wasn't handled in naming convention matching

New test cases added:
- TestImportExtraction: 7 tests for import statement parsing
  - Basic imports, multiple imports, wildcard imports
  - Static imports, static wildcard imports, deeply nested packages
  - Mixed import scenarios
- TestMethodCallDetection: tests for method call detection in tests
- TestClassNamingConventions: 3 tests for naming patterns
  - *Test, Test*, *Tests suffix/prefix patterns

All tests verified against real aerospike-client-java test files:
- TestQueryBlob correctly imports Buffer class
- TestPutGet correctly imports Assert, Bin, Key, etc.
- TestAsyncBatch correctly imports batch operation classes

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The test_detect_fixture_project test expects the java_maven fixture
directory to have a pom.xml file for Maven build tool detection. Add
the missing pom.xml with JUnit 5 dependencies.

Also add .gitignore exception to allow pom.xml files in test fixtures.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@misrasaurabh1 misrasaurabh1 merged commit d714e54 into omni-java Feb 3, 2026
23 of 26 checks passed
@misrasaurabh1 misrasaurabh1 deleted the fix-java-test-discovery branch February 3, 2026 00:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants