ArchUnit: Testing the Design of Your Library
A common issue that is experienced in software development is the disconnect between how the software is described as working and how it works in reality. This often can be caused by a well-meaning developer coming before you and either misunderstanding how the system works and documenting that misunderstanding as truth or documenting the reality at the time but the documentation has fallen out of sync with the system as the software has evolved. Along those same lines, what is defined as the standards in the system can be disconnected from reality. This may happen even without the developer knowing they are disconnecting the code from the standards. Without something confirming and verifying that the code is working and structured the correct way, we can never be sure without extensive work.
Thankfully, to verify that the software solves the business requirements it is supposed we can develop and lean on automated testing. Via a suite of unit, integration, and end-to-end tests we can codify that the software works in a specific way. If the software evolves in a way that it is no longer compatible with the automated tests passing we either have to decide that the requirements have changed (at which point we need to change the test) or that the code has violated a requirement (at which point we need to change the code). This process is well understood in the industry…
