ArchUnit Trends

[vrish88]

Hello there,

I just came across FreezingArchRule, it's AWESOME! One thing that's been tough with ArchUnit is that either a codebase is perfect or it's in complete violation. Codebases with existing problems were tough to wrangle in small chunks. However freeze is one tool to take smaller steps towards that perfection.

One other step I've been looking for to help get codebases better, is to show trends of violations over time. So the use cases I've encountered are something like this:

A codebase has an egregious number of bi-directional JPA relationships. Changing those is hard and risky. However the team has determined that it's important to reduce that risk and they want to make sure they are making progress on it, in a responsible fashion. How can they know that they are making progress?

Or another one:

A new developer joins the team, it appears that there are several bad practices/patterns being applied all throughout the code. After a discussion, the team agrees that, yes, these patterns are bad. However after a few weeks, the team slips into old habits. How can this single new developer help get the team to see what it is doing?

Do these makes sense? Is there something like this that already exists within ArchUnit that I'm missing? Or is this something that you would be open to contributions for?

[hankem]

If your CI ensures that violation stores for frozen rules are always up to date (when violations are fixed, FreezingArchRule automatically reduces stored violations), the history of those store files already tracks the violations over time.

So far, ArchUnit didn't focus on visualizing those (you could use external tools to, e.g., count the text files' lines), but it does provide extension points that allow for custom violation stores. @stefanroeck has implemented an XmlFileBasedViolationStore that can probably directly be used as a SonarQube metric, see #425.

[codecholeric]

What we have also done in the past is committing and pushing the violation store after each CI run. A poor man's visualization can then be achieved by a simple tracking of the text based violation store in the Git repo and counting the lines of each commit, e.g. wc -l ${STORE_VIOLATION_FILE}. So any tool that can visualize a simple counter over time can then be used.