¿Puede usted unidad de prueba de código ofuscado?

Question

Estoy buscando ofuscar nuestro código de la aplicación web Java dentro de nuestro script de compilación Ant existente, pero estoy teniendo problemas con las pruebas unitarias. Ofusco el código justo después de que se compiló, antes de que se manipule y antes de que se ejecuten las pruebas unitarias.

Sin embargo, si ofusco mi código de producción y no mi código de prueba, todas mis pruebas fallan porque están tratando de llamar a métodos que ya no existen porque el ofuscador los ha cambiado. Puedo marcar ciertos métodos para no ofuscarlos para que puedan ser utilizados por sistemas externos como nuestro banco de pruebas, pero como estamos filmando para una cobertura de prueba de unidad alta necesitaremos marcar todos de nuestros métodos como no ofuscables.

Si ofuscar las clases de prueba, así, me encuentro con dos problemas:

1: Las clases de producción y las clases de prueba quedan fusionadas en el mismo directorio de salida y no soy capaz de excluir a las clases de prueba de la producción archivos .jar

2: no puedo ejecutar mi normales hormiga llamada batchtest:

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

porque el ofuscador ha cambiado los nombres de las pruebas.

Podría simplemente ejecutar el ofuscador en los archivos .war/.ear resultantes, pero quiero que nuestras pruebas unitarias se ejecuten contra el código modificado para eliminar cualquier error provocado por el ofuscador.

Actualmente estoy trabajando con Zelix KlassMaster, pero todavía estoy en la fase de evaluación, por lo que estaría abierto a otras opciones si funcionaran mejor.

Answer 1

¿Se puede decir que se ejecute la Ofuscador tal que refactors efectivamente el código incluyendo las referencias de las pruebas (es decir, cuando el nombre de la producción de cambios, el código de prueba cambia su referencia), pero no para ocultar las pruebas mismas (es decir, ¿no cambian los nombres de las clases de prueba o sus métodos)? Dada la experiencia previa con ofuscantes, espero que eso funcione.

Así, por ejemplo, supongamos que tenemos fuente unobfuscated de:

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

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

Quiere configurar las opciones de la ofuscador para que sea efectivamente:

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

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

De esa manera su "run las pruebas "Las tareas Ant deben poder permanecer igual, porque la API de las pruebas no ha cambiado, simplemente la implementación de los métodos.

Answer 2

El ofuscador no debe cambiar sus llamadas públicas. Parece que debes ejecutar las otras pruebas antes de la ofuscación porque verifican la funcionalidad interna que no debería cambiar después de la ofuscación.

Entonces, si ese es el caso, ¿por qué no simplemente ejecutar las pruebas que llaman funcionalidad pública? Todo lo que necesita hacer es tener una clase separada con esas llamadas y volver a compilarla usando el código ofuscado y luego ejecutar ese dll.

Answer 3

Uso yguard (es gratis, por eso lo menciono).

Debería poder decirle al ofuscador que no ofusque ciertas cosas (buscando here parece que puede).

Como han dicho otros, no confundas las pruebas, pero ofusca el resto.

Sin embargo, sugeriría que haga lo siguiente:

1. compilar
2. tarro de los archivos de las Naciones Unidas-ofuscado (si se desea)
3. prueba los archivos un-ofuscado
4. si pasan las pruebas luego ofuscar tarro los archivos ofuscados
5. probar los archivos ofuscados

Será más lento, pero si las pruebas fallan en el paso 3 será más fácil solucionarlo (potencialmente) y si las pruebas fallan en 5, entonces sabrá que hay un problema con la ofuscación, no con su código fuente.