In complex multiyear, multiperson software development life cycles, we usually start with an existing code base as well as preexisting test suites. Also, it is very common that there is no clear map of test cases to source files. A lot of teams actually do not have any documentation or any form of retrievable media in place that identifies what parts of the executable are touched by a given test case in the test repository.
However, many teams follow standard naming conventions and divide the source code and test code into hierarchical directories, as shown in Figure 11-3, to provide some heuristics of tests to source association at a higher level.
But this association may not be a true representation of test suites to features association in the executable. So, running a batch of test suites based on code change in a given code module is at best guesswork and does not guarantee a good change-centric testing approach.
Figure 11-3. Source and tests organization
So, how can we create a change-centric testing baseline for this type of project?
Understanding the caller–callee dependency between the functions/methods in the executable.
This step involves generating the call graph of the executable state space after running all automated, manual, and ad-hoc test cases that are available in your project. ...