tree 24aa068d503469cc0ab2b28c5a07f5c51c4192a8
parent 5bece707f8a08481f28b991a8936f76a5dce3221
author Morten Krogh-Jespersen <mkroghj@google.com> 1551951312 +0100
committer Morten Krogh-Jespersen <mkroghj@google.com> 1551951312 +0100

Split applymapping tests into source and shrunken library

This CL prepares tests for a fix to using applymapping with a proguard
mapping file for naming output where the library is either provided as
program source or library, but unobfuscated. Almost all tests are
relevant for the use case where the library is obfuscated, thus we
duplicate tests.

The logic has changed in the following tests:

InnerEnumValuesTest
-------------------
This test assumed that when renaming enum-values
that the backing string would also be renamed. Thus, if we have:

enum {
  STATE_X,
  STATE_Y
}

and map:

STATE_X -> a
STATE_Y -> y

the test would assert that:

system.out.print(STATE_X).equals("a")

We should generally not change the backing name in strings of enum
values.

MemberResolutionAsmTest
-----------------------
This tests that:

public class A {
  public void foo() { ... }
}

public class B extends A {
  private void foo() { ... }
}

and a mapping file:

A.foo -> a;

what should happen to B.foo.

Notice that this code does not compile and only happens if one links
against libraries where methods has been made private or if the code
is manually written or created with separate compilation.

In this case, one probably named foo to give it exactly the same name
as the base method. The test is changed to then expect B.foo to be
renamed to a.

WhenToApplyTest
---------------
This test tested what would happen if a mapping file was given with
applymapping and we have minification enabled. Given a mapping file
means that one gives an explicit map for how all types should be
named, so this test no longer applies. Nothing in this test was not
tested elsewhere so it has been removed.

Bug: 126503704
Bug: 123092153
Bug: 121305642
Change-Id: Ida14467eabc0f35a8b50cbe3938bccbe3be93cf9