Test module ?

[glelouet]

The test in JCM mostly use code matching.

This is weird because this should instead be checked using compiler.

I propose the following changes :

1. a /jcodemodeltests module, with whatever groupId:artifactid ; depends on main JCodemodel module.
2. a @JCMTested annotation to place on the test classes that generate JCodemodel instances
3. an annotation processor that generates the corresponding classes in src/test/generated

This way I could have a test class in src/main/java with

public JCodemodel createSimpleIntRecord(){
// do the creation and return the CM
}

and the corresponding test in src/test/java with

  @Test public void testSimpleIntRecord(){
  SimpleIntrecord sr = new SimpleIntRecord(24);
}

That's the basic idea, if yo have better one I'm all hear.

[phax]

CodeModelTestsHelper.parseCodeModel (cm); does indeed parse using the Eclipse JDT compiler. Doesn't that do the trick?

[glelouet]

No, because you can't use the created class.
I had made the memorycompiler for this years ago.
For example I want to check that making an

public record EvenRecord(int n){
  public EvenRecord {
   if(n%2!=0) throw new IllegalArgumentException("only accepts even value, received "+n);
  }
}

Using jcodemodel, then creating an instance with new EvenRecord(1) would throw an exception.

[glelouet]

Other more complex cases, like complex pattern matches, could need this kind of tests.
They are complex in the sense that many potentially different yet close outcome can be produced.

return switch(sealedInterface){
  case myrecord1(subrecord(var _, var s)) -> s;
  case myrecord2(int size) -> ""+size;
 default -> yield "";
};

[glelouet]

Can't work with annotationprocessor because it can't give access to the Class the annotation is applied to - therefore I can't call the methods.

[phax]

Maybe some URLClassLoader using some in-memory InputStream?

[phax]

And related to #99

[glelouet]

No, I want to have the generated test classes in source dir (or more like, src/generated/javatest ), so as to show what is actually produced .
That's not the issue though.

The issue is that I want to execute all the void-> JCodemodel methods in a class that belongs to a specific package and is annotated as such.
However discovering classes is an issue, it's doable using annotationprocessor but this does not allow to use reflection on the annotated classes (they are provided as typemirror and I can't Class.forName the annotated class).
Would need to look at how it's done in JUnit.

[glelouet]

The idea is :

1. maven adds a source folder for test scope (ok, maven build-helper-plugin)
2. an intermediate phase (typically generate-test-sources) loads the classes that were compiled and iterate over the generation and deletes the output src/generated/testjava dir.
3. those classes are called to create a CM, which is written in the output dir.

Maybe the annotation procesor could just write the list of classes in an intermediate target/ file, then read at generate-test-source phase.

[phax]

Please experiment in a separate submodule - that really sounds very creative ;-)

[glelouet]

yes, it's in a separate submodule :)
/jcodemodeltests as specified in the first message.

[glelouet]

To be fair, that's the behavior I was having in other CPP projects about 20 years ago, regarding auto generating drivers based on their specifications.