ArchUnit does not update lines or method parameters in frozen files

[adavid9]

Hi 👋🏻, I have a test which checks cycles of my application.

freeze(slices().matching("com.somepackage.impl.(*)..").should().beFreeOfCycles());

It generated a file because there are already some violations, but I can't remove them now, so I will store this file in version control and everything will work fine, the test will be green. The problem arises when I want to edit any class that was already in this generated file, let's say I added a new method only, so I didn't enter new violations, but I did an update and now the line has changed, and at this point the test begins to be red again, and after firing, the entire contents of the file previously generated are empty.

Is there a way to fix this problem, so if someone adds new methods, update current, whatever in the current violations that are stored in the frozen files, does not have to update the frozen file manually?

[adavid9]

In the documentation we can see

i.e. if a violation is just shifted to a different line, it will still count as previously recorded and will not be reported.

The problem is when I have a method that was mentioned in the stored frozen file, and I have updated this method with a new parameter, or added a new parameter to the constructor of a class that was also in the frozen file, what in this case? Do I have to update this frozen file manually each time?

[adavid9]

Are there any updates on this one?

[codecholeric]

As for now, only shifted line numbers are ignored, as you found. If you refactor a method signature or make any other bigger changes, then the output of the rule changes in a way that the rule fails. This is also, because it's fairly difficult to determine automatically, what an "accepted" change should be in all contexts.
So yes, either every time you make such an incompatible change you have to "refreeze" the violations (see the refreeze option) or you can adjust how line matching is performed and adjust it in a way that e.g. method parameters are irrelevant (see ViolationLineMatcher). The latter is pretty much a flexible way to hook in your own implementation in that can say for each two lines "are these still the same", so you could write your own logic of "if the lines only differ by the number of method parameters count it as the same".