Feature suggestion: Freeze files and stored.rules validation / sanity check
Hi ArchUnit Team,
First of you do a great job here. ArchUnit is great.
In our project we currently have >70 freeze files in the stored.rules mentioned.
Digging deeper I noticed several things, which I am concerned about.
- The files referenced might not exist anymore, but the reference in stored.rules is
- When freeze files become empty you are not being advised to remove the freezing from your test.
- Freeze files might still be in the archunit folder, but not referenced anymore
- Tests were removed without removing the stored.rules line or freeze file
- stored.rules are not sorted. To make it better human readable it would be nice to have it sorted alphabetically.
Of course in the end it is our job to keep our source code in check and clean up correctly etc.
Yet I wonder how ArchUnit itself can help to have a sanity check of its freeze files and stored.rules?
What is your opinion on this?
Sorry for the late reply, I think it would be a nice addition, if anybody wants to give this a shot I would support it! In the past we've already sorted the actual violations alphabetically to ease human browsing and diffs if I remember correctly.
Hello 👋 I would like to work on this!
Hi @codecholeric
I have created https://github.com/TNG/ArchUnit/pull/1405 which solves parts of the features requested above, request no. 2 to be specific.
- When freeze files become empty you are not being advised to remove the freezing from your test.
If those changes make sense to you I can proceed and update the docs in the same PR.
I can work on the following feature requests in another PR
1- The files referenced might not exist anymore, but the reference in stored.rules is 3- Freeze files might still be in the archunit folder, but not referenced anymore 5- stored.rules are not sorted. To make it better human readable it would be nice to have it sorted alphabetically.
The 4th request
- Tests were removed without removing the stored.rules line or freeze file is more complicated because it requires taking an action by considering the whole test suite. At this point, I don't know if it is possible to achieve that.
I created https://github.com/TNG/ArchUnit/pull/1407 for addressing requests no. 1 and 3. If those changes make sense to you I can proceed and update the docs in the same PR.
It's great to see that there is progress here. Thank you very much.
Regarding empty freeze files.
In our company we have several parameterised tests where we freeze by default. As adding new parameters in our case probably also needs freezing. As the unit test would become ugly if we distinguish between not freezing and freezing depending on parameters. I'm not sure yet what's the best approach is for this case though. Don't create a file as it is not needed I guess?
I'm not sure yet what's the best approach is for this case though. Don't create a file as it is not needed I guess?
I've taken this approach in my PR https://github.com/TNG/ArchUnit/pull/1405 . If the new property default.deleteEmptyRuleViolation=true is set, it will skip creation of empty freeze file.
In our company we're facing empty freeze files for a different reason. We have centrally defined our archunit test set in a library. Some of our tests are freezing because they enforce rules that can be broken in exceptional cases, e.g. use of deprecated classes is allowed for short period to allow enough time to update the code. When we run our archunit tests in different services we get different results, in many cases empty violation files. With these changes I intend to get rid of those empty files.
Hello I'd appreciate a review on the linked PRs
- https://github.com/TNG/ArchUnit/pull/1405
- https://github.com/TNG/ArchUnit/pull/1407
Hi @hankem @codecholeric I'd appreciate your review on my PRs above.