Hello everyone,

I would like to start a discussion on introducing automated tests for more
architectural rather than stilistic topics. For example, here are a few
things that seem worth checking to me (this is Table-API-focused since it
is the subsystem I'm involved in):

(a) All classes in o.a.f.table.api should be annotated with one
of @Internal, @PublicEvolving, or @Public.
(b) Classes whose name ends in *ConnectorOptions should be located in
o.a.f.connector.*.table
(c) Classes implementing DynamicSourceFactory / DynamicSinkFactory should
have no static members of type ConfigOption

There are probably significantly more cases worth checking, and also more
involved ones (these are rather simple examples), like disallowing access
between certain packages etc. There are two questions I would like to ask
to the community:

(1) Do you think such tests are useful in general?
(2) What use cases come to mind for you?

If the idea finds consensus, I would like to use (2) to investigate which
tooling to use. An obvious candidate is Checkstyle, as this is already
used. It also has the advantage of being well integrated in the IDE.
However, it is limited to looking at single files only, and custom checks
are pretty complicated and involved to implement[1]. Another possible tool
is ArchUnit[2], which would be significantly easier to maintain and is more
powerful, but in turn requires tests to be executed. If you have further
suggestions (or thoughts) they would of course also be quite welcome,
though for now I would focus on (1) and (2) and go from there to evaluate.

[1] https://checkstyle.sourceforge.io/writingchecks.html
[2] https://www.archunit.org/


Best
Ingo

Reply via email to