  A few works address the challenge of automating software diversification, and
they all share one core idea: using automated test suites to drive
diversification. However, there is is lack of solid understanding of how test
suites, programs and transformations interact one with another in this process.
We explore this intricate interplay in the context of a specific
diversification technique called "sosiefication". Sosiefication generates sosie
programs, i.e., variants of a program in which some statements are deleted,
added or replaced but still pass the test suite of the original program. Our
investigation of the influence of test suites on sosiefication exploits the
following observation: test suites cover the different regions of programs in
very unequal ways. Hence, we hypothesize that sosie synthesis has different
performances on a statement that is covered by one hundred test case and on a
statement that is covered by a single test case. We synthesize 24583 sosies on
6 popular open-source Java programs. Our results show that there are two
dimensions for diversification. The first one lies in the specification: the
more test cases cover a statement, the more difficult it is to synthesize
sosies. Yet, to our surprise, we are also able to synthesize sosies on highly
tested statements (up to 600 test cases), which indicates an intrinsic property
of the programs we study. The second dimension is in the code: we manually
explore dozens of sosies and characterize new types of forgiving code regions
that are prone to diversification.
