java - generate - junit test android

Eclipse junit testing en el mismo proyecto.

Question

Esta es una pregunta relativamente abierta. Si he creado una aplicación en un proyecto en Eclipse y luego quiero probar este proyecto, debo crear el código JUnit dentro del mismo proyecto o crear un proyecto separado. Por ejemplo...

ShopSystem tal vez sea el nombre de mi proyecto principal. ¿Debo crear un proyecto llamado, por ejemplo, ShopSystemTest ?

En general, ¿a qué distancia "de distancia" se debe almacenar el código de prueba de la carpeta principal del proyecto? Si almaceno el código de prueba dentro del proyecto principal y luego exporto el proyecto principal como un contenedor ejecutable, llevará el código de prueba, lo que no es ideal ...

Sugerencias?

Answer 1

Considere la forma de Maven: En un proyecto de Maven, las mareas se organizan de esta manera.

src
|--main
| |--java
|--test
|--java

Su código fuente va en src / main / java, su código de prueba junit va en src / test / java, ambos son carpetas de origen (y como consecuencia, puede colocar su código jUnit en el mismo paquete que su código Java, una carpeta de origen diferente).

El interés es que para la codificación habitual, sus clases jUnit están en paquetes de código, pero en la creación de archivos jar, puede tomar clases provenientes de src / main / java y no liberar sus pruebas.

Answer 2

Me gusta mucho la convención de expertos: hay un árbol de origen separado para main y test en el mismo proyecto, el código principal se implementa, el código de prueba no. Las estructuras de paquetes pueden ser (pero no tienen que ser) idénticas.

project
src
main
java // source files
resources // xml, properties etc
test
java // source files
resources // xml, properties etc

Y en eclipse, cuando elige new -> JUnit test case , simplemente cambia la carpeta de origen a src / test / java y deja el paquete sugerido como está.

(Uno de los beneficios de permanecer en el mismo paquete es tener acceso a miembros protegidos y de ámbito de paquete, aunque esto no es un comportamiento de prueba de unidad "adecuado")

Actualización: Aquí hay un código para ilustrar mi último punto:

Clase principal (en src / main / java):

package com.test;
public class Foo{
static class Phleem{
public Phleem(final String stupidParameter){
}
}
String bar;
protected String baz;
protected Object thingy;
}

Clase de prueba (en src / test / java):

package com.test;
import org.junit.Test;
public class FooTest{
@Test
public void testFoo(){
final Foo foo = new Foo();
foo.bar = "I can access default-scoped members";
foo.baz = "And protected members, too";
foo.thingy = new Foo.Phleem("And I can access default-scoped classes");
}
}

Answer 3

Si bien no hay una única manera correcta, el enfoque habitual es mantener las pruebas unitarias en el mismo proyecto.

Puede crear una segunda carpeta de origen (como test ), donde coloca sus clases de prueba en los mismos paquetes que las clases bajo prueba. Esto también le permite probar clases privadas de paquetes sin inundar sus paquetes fuente principales con clases de pruebas.

La estructura de la carpeta / paquete fuente se vería así:

-sources
-main
-my.package
-MyClass.java
-test
-my.package
-MyClassTest.java

Luego puede configurar su compilación para que no incluya la carpeta de origen de test al empaquetar el JAR.

Answer 4

Típicamente tienes

/src/main/java (for codes)
/src/test/java (for tests)