CC007

For completeness, here is how the test would look with the `Cases`/`Elements` test method parameter: ```java import com.karuslabs.elementary.junit.Tools; import com.karuslabs.elementary.junit.ToolsExtension; import com.karuslabs.elementary.junit.annotations.Inline; import com.karuslabs.utilitary.type.TypeMirrors; import javax.lang.model.element.Element; import java.util.List; import java.util.Map;...

I also think that `Cases.get(int index)` can be removed if needed, as it seems very error-prone to retrieve elements without label, especially if you retrieve them from a possibly nonexistent...

I don't think that the proposed Element annotation would ever conflict with that API, except when someone tests an annotation processor that processes annotations that are used in an annotation...

> Would one still need "case" to make parameterized test cases? > Is "case" needed for nonparameterized test cases, does it even make sense? case doesn't make sense for non-parameterized...

> I disagree since doing static code analysis in an annotation processor will almost always rely on the [Element](https://docs.oracle.com/javase/8/docs/api/javax/lang/model/element/Element.html)/TypeMirror API, which IMO is quite a common use-case. I do agree...

Ah ok. The annotation processor does indeed heavily rely on Element, but the code that actually would be given the `@Element` annotation wouldn't usually rely on Element, right? As this...

> Perhaps another issue at hand here is the discoverability of `@Introspect`? Ah while I had seen `@Introspect`, I hadn't looked into what it does. Most of my knowledge comes...

For the `single()` implementation you can also use `elements.values().get(0)`. That way you can remove the unnecessary loop and `throw new IllegalStateException("This exception should never be thrown");`

Also, you could use the [TestAbortedException](https://ota4j-team.github.io/opentest4j/docs/1.0.0/api/org/opentest4j/TestAbortedException.html?is-external=true) (which is also used by Junit Jupiter uses for test assumptions), instead of the IllegalStateExceptions

Fair. While I believe that the dependency is included with Junit Jupiter, it is always good to not rely on transitive dependencies and to use as few dependencies as possible...