When we write integration tests, we consider three categories of configurable parameters.
Part of the test
Many test developers learned enough to avoid hardcoding stuffs, but often they mix those in one file. Some operation specific parameters such as default timeout value can be easily overridden even if it’s mixed with other properties, but we can’t easily replace the set of environment specific parameters at the operation time. As a result, we see duplicate copies of operation specific parameters embedded in ‘test-env.properties’ and ‘stage-env.properties’. Even worse are ‘part of the test’ properties. UI tests utilizing Page Object Model will come with the xpath strings or other forms of identification for an object on a page. If these are mixed with the aforementioned property files, it would be a nightmare to maintain them.
Number of environment specific parameter files should match number of test environments in concern. Number of operation specific parameters should be ideally one. Operation specific parameters are replaced one by one but rarely by the set. Part of the test parameters should be placed in a same folder structure of the classes that need them. For example, if POM class structure has 3 depth tree structure, the resources files should match it.
In the end, we want to run a test suite like this: >mvn test -Dgroups=regression -Denv=test-env -Dretry=3