The first part of this post introduced parameterized tests to avoid missing or unnecessary translation resources. I also showed an example of a possibly parameterized test, which was to outline how good test failure design helps to find all errors instead only the first or have static variables.
Being part of a software development team, bound to an organization leads to a variety of agreements. As a Java developer I often adhere to the mature rules from Effective Java (Joshua Bloch) or from the Design Patterns Book of the Gang of Four (Erich Gamma et al). To bring that idea to future developers I often use Unit tests to express the common sense behind these rules as code. And I don't overdo it but use parameterized tests excessively. So my code does not only contain the technical solution to a functional requirement and the necessary unit tests. In addition I provide unit tests for the non functional requirements. As an introduction I chose internationalization (i18n) requirements to be unit tested.