Este es un relativamente pregunta abierta. Si he creado una aplicación en un proyecto en Eclipse y luego quiero probar este proyecto, debo crear la JUnit código dentro de un mismo proyecto o crear un proyecto independiente. Por ejemplo…

ShopSystem tal vez el nombre de mi proyecto principal – debo crear un proyecto denominado decir, ShopSystemTest?

En general – ¿qué tan lejos «lejos» si el código de prueba se almacenan a partir de la carpeta de proyecto principal? Si me almacenar el código de prueba dentro del proyecto principal y, a continuación, exportar el proyecto como un jar ejecutable va a tomar la prueba de código, que no es lo ideal…

Sugerencias?

InformationsquelleAutor david99world | 2010-08-26

4 Comentarios

  1. 67

    Mientras que no existe un sólo camino correcto, el enfoque usual es mantener la unidad de las pruebas en el mismo proyecto.

    Puede crear una segunda carpeta de origen (como test), donde pones tu clase de prueba en los mismos paquetes, ya que las clases bajo prueba. Esto también permite que usted paquete de prueba-clases particulares mientras no la inundación de su principal fuente de paquetes con clases de prueba.

    Su carpeta de origen/estructura del paquete tendría este aspecto:

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

    A continuación, puede configurar su construcción no incluir el test carpeta de origen a la hora de empaquetar el FRASCO.

  2. 21

    Me gusta el maven de la convención de mucho: Hay un árbol de código fuente principal y prueba en el mismo proyecto de código principal que se ha implementado, el código de prueba no. Paquete de estructuras puede ser (pero no tiene que ser) idénticos.

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

    Y en eclipse, cuando usted elige new -> JUnit test case, que acaba de cambiar la carpeta de origen en src/test/java y salir de la propuesta de paquete como es.

    (Uno de los beneficios de permanecer en el mismo paquete es el de tener acceso a protegido y paquete ámbito de miembros, aunque esto no es ‘correcto’ de la unidad de prueba de comportamiento)


    Actualización: Aquí un poco de 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");
        }
    
    }
    • «el acceso a la protegida y paquete ámbito de miembros» – para tener acceso a los miembros protegidos, tendrías que crear una subclase de la clase bajo prueba. Lo que quieres decir es que ser capaces de acceder paquete ámbito de las clases, ¿verdad?
    • Ah, y los miembros también, por supuesto, usted está en lo correcto. He usado por defecto ámbito de miembros tan raramente que a veces me olvido de que existen.
    • Ouch! Yo no sabía protected permite el acceso de otras clases en el mismo paquete. Bueno, que borra las cosas, gracias.
    • sí, la totalidad de acceso a nivel de concepto es bastante estúpida. por ejemplo, no hay manera de hacer que los paquetes accesibles para los sub-paquetes sin hacer las clases públicas. scala tiene un sistema mucho mejor que hay.
    • Estoy de acuerdo. Si Java fue diseñado el día de hoy, privado probablemente sea el predeterminado, protegido se permite el acceso sólo a partir de las subclases, no sería un concepto de sub-paquetes, y final sería el valor por defecto para las clases, variables locales y tal vez incluso miembros. Oh, bueno.
    • final sería por defecto? que significa que vaya a haber una palabra clave para marcar las clases y métodos como extensible? No estoy seguro de si me gustaría que porque usted tendría que error de la API de diseñadores de todo el tiempo a favor de añadir la palabra clave para este y ese método.
    • Bueno, iba a poner con la regla de diseño y el documento de la herencia o prohibir (Josh Bloch) derecho a la lengua. OMI difícilmente puedes extender una clase así que no estaba diseñado para que desde el suelo hacia arriba.
    • Lo sé, he intentado ampliar la Hibernate Validator una vez. Me dio hasta pronto y re-escribió la mayoría de…

  3. 4

    Considerar el maven manera : En un proyecto de maven, soruces se organizan de esta manera

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

    Su código fuente va en src/main/java, su prueba de junit código va en src/test/java, ambos están en la carpeta de origen (y como consecuencia que usted puede poner su jUnit código en el mismo paquete que el código de Java, pero en diferente carpeta de origen).

    Que el interés es que para los habituales de codificación, su jUnit las clases son en los paquetes de código, pero en la jarra de la creación, usted puede tomar clases viene sólo de src/main/java y no la liberación de sus pruebas.

Dejar respuesta

Please enter your comment!
Please enter your name here