Можете ли вы юнит тестировать запутанный код? - PullRequest
Новая
       28

Можете ли вы юнит тестировать запутанный код?

6 голосов
/ 20 марта 2009

Я пытаюсь запутать код нашего веб-приложения на Java в существующем скрипте сборки Ant, но у меня возникают проблемы с модульным тестированием. Я запутываю код сразу после того, как он был скомпилирован, до того, как он будет создан, и до запуска модульных тестов.

Однако, если я запутываю свой производственный код, а не тестовый код, все мои тесты не выполняются, потому что они пытаются вызвать методы, которых больше не существует, потому что они были переименованы обфускатором. Я могу пометить некоторые методы, чтобы не запутывать их, чтобы они могли использоваться внешними системами, такими как наш набор тестов, но, поскольку мы стремимся обеспечить высокий уровень охвата тестами, нам необходимо пометить все наших методов как obfuscatable.

Если я также запутываю тестовые классы, я сталкиваюсь с двумя проблемами:

1: производственные классы и тестовые классы объединены в одном выходном каталоге, и я не могу исключить тестовые классы из рабочих .jar-файлов

2: я не могу запустить свой обычный групповой вызов Ant: 

 <batchtest todir="${basedir}/reports">
      <fileset dir="${basedir}/components/common/build-zkm">
           <include name="**/*Test.class"/>
      </fileset>
 </batchtest>

потому что обфускатор изменил названия тестов.

Я мог бы просто запустить обфускатор для получающихся файлов .war / .ear, но я хочу, чтобы наши модульные тесты запускались с измененным кодом, чтобы устранить любые ошибки, вызванные обфускатором.

В настоящее время я работаю с Zelix KlassMaster, но я все еще на стадии оценки, поэтому я буду открыт для других вариантов, если они будут работать лучше.

Ответы [ 3 ]

7 голосов
/ 21 марта 2009

Я использую yguard (это бесплатно, поэтому я упоминаю об этом).

Вы должны быть в состоянии сказать обфускатору не запутывать некоторые вещи (глядя здесь , кажется, вы можете).

Некоторые, как говорили другие, не запутывают тесты, а запутывают все остальное.

Однако я бы посоветовал вам сделать следующее:

  1. компиляция
  2. jar необфусцированных файлов (при желании)
  3. проверить необфусцированные файлы
  4. если они пройдут тесты, то запутайте файлы запутанных файлов
  5. проверка обфусцированных файлов

Это будет медленнее, но если тесты не пройдут на шаге 3, их будет легче исправить (потенциально), а если тесты не пройдут на 5, то вы знаете, что существует проблема с запутыванием, а не с исходным кодом.

3 голосов
/ 20 марта 2009

Можете ли вы сказать ему, чтобы он запускал обфускатор так, чтобы он эффективно рефакторинг кода , включая ссылки из тестов (т. Е. При изменении имени продукта, код теста меняет свою ссылку), но не для запутывания сами тесты (т.е. не меняйте имена тестовых классов или их методов)? Учитывая предыдущий опыт работы с обфускаторами, я ожидаю, что это сработает.

Например, предположим, что у нас есть необъяснимый источник: 

public class ProductionCode
{
    public void productionMethod() {}
}

public class ProductionCodeTest
{
    public void testProductionMethod()
    {
        new ProductionCode().productionMethod();
    }
}

Вы хотите установить параметры обфускатора, чтобы сделать его эффективным : 

public class Xyzzy
{
    public void ababa() {}
}

public class ProductionCodeTest
{
    public void testProductionMethod()
    {
        new Xyzzy(). ababa();
    }
}

Таким образом, ваши задачи Ant «выполнить тесты» должны быть такими же, потому что API тестов не изменился - только реализация методов.

0 голосов
/ 20 марта 2009

Обфускатор не должен менять ваши публичные звонки. Похоже, что вам следует запустить другие тесты перед запутыванием, потому что они проверяют внутреннюю функциональность, которая не должна меняться после запутывания.

Так что, если это так, почему бы просто не запустить тесты, которые вызывают публичную функциональность? Все, что вам нужно сделать, это иметь отдельный класс с этими вызовами и пересобрать его, используя запутанный код, а затем запустить эту dll.

...