The newest implementation of BasicTypeLink#getCtElement(9

seems not to work anymore. The result of the method call always returns null. The method works on version 0.6.3 but not on 0.7.0-SNAPSHOT.

Add parameters (e.g., lists) to define whitelisted and blacklisted modifiers in classes, attributes and methods in Reflection Utils.

Why we shouldn't ditch the old Reflection API just yet

The Problem

The new Reflection API was build from the Ground using better Patterns and being much more versatile in it's application. At least in theory. In #74 we deprecated the reflection API stating that the new API is ready to replace it. However after using the new reflect API for a more complex Assignment where Students have to declare their own Classes, i realize it's still very much incomplete.

new vs old API

Here is a comprehensive List of things that are currently missing in the new API but are present in the old API. Until all of these are ported to the new API, we should imo not remove or deprecate the old one.

• documentation. Like seriously, half of the code doesn't even have Javadoc...
• checking if a method from an interface is implemented
• verifying no blacklisted statements were used
• automatically invoking methods with random values to see if they are callable at all
• still being able to invoke methods even if students miss or reorder parameters (omitting the missing args)
• automatically writing tests for getters/setters
• automatically verifying the method signature, not just the parameters (including throws, generic type, maybe annotations)
• automatically test that constructor saves parameters in private attributes
• automatically generate instances of interfaces and abstract classes using Mockito
• bridge for Mockito verifiers (e.g. somethink like methodLink.verify(mock,times(5))
• bridge for Mockitos when (e.g. methodLink.when(mock,<Answer>))
• lazy evaluation (Class tested had .resolve(), currently needs hacky workaround using sth like Suppliers.memoize() from Guava)
• utility methods for reflective access such as typeLink.setField(obj) and typeLink.setFieldTyped(obj,clazz)
• unified error messages. Almost every single assertion command requires a pre comment supplier without providing any useful comment itself.
• easy to understand import structure: The seperation of Assertions2, Assertions3, Assertions4, etc. Makes it very hard to understand where the desired Utility Method lies. We should have all assertion methods at least in one appropriately named file.
• syntactic sugar. There are many instances where the old API is just more convenient to use. Especially the fact that you have to use a Matcher for almost everything without an overload to provide the actual value instead. For example in order to create an instance of a class you used to be able to just call new ClassTester(clazz).resolveInstance(param1,...) which first tried to create an instance by using the constructor, then as a fallback returned a mock. With the new API you have to
  • get a TypeLink tl By calling BasicTypeLink.of(clazz);
  • get a ConstructorLink cl by calling Assertions3.assertConstructorExists(tl,BasicReflectionMatchers.sameTypes(args)); (for args you then have to create a Type link for every arg again...)
  • manually handle the errors and create something like this:

/**
 * Creates an instance of the given class using the given constructor and the given arguments. If this fails, a mock
 * instance is created instead with "CALLS_REAL_METHODS" enabled.
 *
 * @param classLink       the class to instantiate
 * @param constructorLink the constructor to use
 * @param args            the arguments to try to pass to the constructor
 * @return the created instance
 */
@SafeVarargs
public static Object createInstance(
    BasicTypeLink classLink,
    ObjectCallable<BasicConstructorLink> constructorLink,
    ObjectCallable<Object>... args
) {
    Object instance;
    try {
        instance = constructorLink.call().invoke(Arrays.stream(args).map(Assertions2::callObject).toArray());
    } catch (Throwable e) {
        instance = mock(classLink.reflection(), CALLS_REAL_METHODS);
    }
    return instance;
}

What now?

I think i will still use parts of the old API for my personal Tests until the new one is matured. However i really prefer the new structure as it has a lot more potential. So porting the old functions over should be one of our top priorities this year as i started in #129.

Example code:

var scanRobots = Assertions2.callObject(
	controlCenter::initScanRobots,
    context,
    r -> "The method `initScanRobots` threw an exception."
);

If the initScanRobots method throws an exception, an NPE is thrown here because the actual field is null.

Instead, I would expect this to throw an AssertionFailedError with the exception thrown by initScanRobots as a cause, just like Assertions2#call.

A possible fix might be to just add Nothing.nothing() as the actual value to the builder here.

Add a functionality to disable throwing of CrashExceptions on calls of crash.

There are situations in which it is unpractical that a CrashException is thrown unavoidably. For example, if a method is called in each run of a program but the method needs to be implemented in a later exercise.

Add an utility class for easily reading string and primitive values from property files as supported by java.util.Properties.

This feature is required for exercise FOP-2223-H01.

The HTML Exeptions are nice for working with Jagr Runs, but are a nightmare when debugging using regular Junit5. We should revert to regular Assertion Errors that are displayed nicely in most modern IDEs when not in a Jagr run.

To check whether or not we currently are in a Jagr run take a look at the JagrExecutionCondition to see how it's done:
https://github.com/sourcegrade/jagr/blob/26e3a49a6c4f8fa647a01c4dd1b83bedb4b6732c/grader-api/src/main/java/org/sourcegrade/jagr/api/testing/extension/JagrExecutionCondition.java#L29-L38

BasicMethodLink#getCtElement() is unable to return a CtMethod in case the declaring class is a record or if the method is synthetic. An ArrayIndexOutOfBoundsException is thrown instead.

Add concatability of tests, e.g., operations like "and" and "or".

provide an equivalent for check-expect in java.
The idea here is to write tests in a Main method, and the result of the test can then be stored in a static context and accessed for a final print statement and for automated test evaluation. Also, the output should be color coded.

Provide a simple way to access files in the resource folder to keep focus on working with files instead of project specifics.

In this Method we should use Throwable instead of Exception, for Example if the Invocation is an org.mockito.exceptions.base.MockitoAssertionError (which can be thrown when using verify() with Mockito)

Same here:

TBD

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update plugin org.jetbrains.kotlin.jvm to v1.9.25
• chore(deps): update dependency gradle to v8.10
• fix(deps): update dependency org.junit.jupiter:junit-jupiter to v5.11.0
• fix(deps): update dependency org.mockito:mockito-core to v5.13.0
• chore(deps): update actions/deploy-pages action to v4
• chore(deps): update actions/upload-pages-artifact action to v3
• chore(deps): update plugin org.jetbrains.kotlin.jvm to v2
• fix(deps): update dependency fr.inria.gforge.spoon:spoon-core to v11
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

We should deprecate my old ReflectionUtils as it is superseeded by the new reflect api

Add a method in TypeLink and MethodLink showing all used classes.

Add higher-order functions for testing if a method is implemented. A method is implemented, iff the call of the method does not result in an CrashException. If a method is not implemented, an AssertionFailedError calling not implemented should be thrown.

We should provide a hosted version of the javadoc

The commit (5ae4473) introduced annotations where fields, method, classes, constructors and local variables can be annotated but at the moment we cannot annotate classes and constructors.

TBD

The current version 0.3.1 shows a vulnerability warning in IntelliJ. Apparently, a package is used, for which a CVE exists.

Add tutor utilities for generating rubric comments.

If a criterion is not fulfilled and the corresponding method is implemented, the comment should contain the following information:

• name of method
• actual parameters
• expected return
• actual return
• (expected side effects)
• (actual side effects)

There should be an option to make non-displayable objects displayable, e.g., by adding to-string transformers for displayed objects.