¿Cómo probar el código fácilmente?

Question

Estoy aprendiendo Java leyendo "Head First Java" y haciendo todos los acertijos y exhibiciones. En el libro que recomiendan para escribir las clases de TestDrive para probar el código y las clases que he escrito, es una cosa realmente simple de hacer, pero al hacer esto creo que no puedo probar completamente mi código porque estoy escribiendo el código de prueba sabiendo lo que quiero obtener, no sé si tiene algún sentido, pero me preguntaba si hay alguna manera de probar mi código de una manera simple para que me diga lo que no está funcionando correctamente. Gracias.

Answer 1

¿Qué entendemos por código? Cuando realizo la prueba unitaria, que es de lo que creo que estamos hablando aquí, estamos probando métodos y clases específicos.

creo que no puedo probar completamente mi código porque yo estoy escribiendo el código de prueba saber lo que quiero conseguir

En otras palabras, se está investigando si algún código cumple un contrato . Considere este ejemplo:

int getInvestvalue(int depositCents, double annualInterestRate, int years) { 

} 

¿Qué pruebas puede idear? Si ideas un buen conjunto de pruebas, puedes tener cierta confianza en esta rutina. Entonces podríamos probar este tipo de entrada:

deposit 100, rate 5.0, years 1 : expected answer 105 
    deposit 100, rate 0, years 1 : expected answer 100 
    deposit 100, rate 10, years 0 : expected anwer 100 

¿Qué más? ¿Qué tal una tasa negativa?

Más interesante aún, ¿qué tal una tasa de interés muy alta como 1,000,000.50 y 100,000 años? ¿Qué sucede con el resultado? ¿Encajaría en un entero? ¿Qué hace esta prueba? ninguna excepción documentada?

Surge entonces la pregunta: ¿cómo averiguamos esos casos de prueba. No creo que haya un solo enfoque que conduzca a la construcción de un conjunto completo, pero hay un par de cosas que considerar:

1. Bordes: cero, uno, dos, muchos. En mi ejemplo, no solo hacemos una tasa del 5%. Consideramos especialmente los casos especiales. Zero es especial, uno es especial, negativo es especial, un número grande es especial ...
2. Estuches de esquina: combinaciones de bordes. En mi ejemplo, es una gran tasa y una gran cantidad de años. Escoger esto es algo así como un arte, y nos ayuda nuestro conocimiento de la implementación: aquí sabemos que hay un efecto "multiplicador" entre tasas y años.
3. Cuadro blanco: utilizando el conocimiento de la implementación para conducir la cobertura del código. Ajustando las entradas para forzar el código hacia abajo en caminos particulares. Por ejemplo, si sabe que el código tiene una ruta condicional "si la tasa es negativa", entonces esta es una pista para incluir una prueba de tasa negativa.

Answer 2

Uno de los principios de "Test Driven Development" es escribir primero una prueba (es decir, antes de haber escrito el código). Obviamente, esta prueba fallará inicialmente (su programa puede incluso no compilar). Si la prueba no falla, entonces sabrá que tiene un problema con la prueba en sí. Una vez que falla la prueba, el objetivo se convierte en seguir escribiendo código hasta que pase la prueba.

Además, algunos de los frameworks de pruebas unitarias más populares como jUnit le permitirán probar si algo funciona o si no funciona explícitamente (es decir, puede afirmar que se produce un cierto tipo de excepción). Esto se vuelve útil para verificar entradas incorrectas, casos de esquina, etc.

Para robarle una frase a Stephen Covey, solo comience con el final en mente y escriba tantas pruebas como pueda imaginar. Esto puede parecer trivial para un código muy simple, pero la idea se vuelve útil a medida que avanzas hacia problemas más complejos.

Answer 3

correcto - usted sabe qué esperar, y escriba casos de prueba para cubrir ese conocimiento. En muchos aspectos, esto es normal: quieres probar lo que has escrito para que sepas que funciona como esperas.

ahora, necesita llevarlo al siguiente paso: encuentre un sistema donde estará funcionando (es decir, integrelo con otras partes y piezas del rompecabezas completo) y vea si todavía funciona de acuerdo con sus suposiciones y conocimiento .

Luego debe dárselo a otra persona para que lo pruebe; rápidamente encontrarán los bits que nunca pensó.

Luego se lo das a un usuario real, y no solo encuentran las cosas en las que ni tú ni tu probador pensaron nunca, sino que también encuentran las cosas que el analista de requisitos nunca pensó.

Esta es la forma en que funciona el software, y posiblemente la razón por la que nunca termina.

PS. Una cosa sobre su código de prueba es más importante que nada: una vez que lo haya hecho una vez y descubrió que funciona como se esperaba, puede agregar más cosas a su aplicación y luego ejecutar nuevamente el código de prueba para asegurarse de que siga funcionando como se esperaba . Esto se llama prueba de regresión y creo que es la única razón para escribir sus propias pruebas unitarias.

y: Dilbert's take on testing.

Answer 4

de Prueba de

No, usted debe escribir JUnit o TestNG pruebas.

Answer 5

Hecho correctamente, sus pruebas son su especificación. Define lo que su código debe hacer. Cada prueba define un nuevo aspecto de su aplicación. Por lo tanto, nunca escribiría pruebas buscando cosas que no funcionan correctamente, ya que las pruebas especifican cómo las cosas deberían funcionar correctamente.

Una vez que piense que ha terminado las pruebas unitarias y codificando su componente, una de las mejores y más fáciles formas de aumentar la confianza de que las cosas funcionan correctamente es usar una técnica llamada Exploratory Testing, que puede considerarse una exploración sin guiones de la parte de la aplicación que has escrito buscando errores basados ​​en tu intuición y experiencia (¡y tortuosidad!).

Pair Programming es otra gran manera de prevenir y eliminar los errores de su código. Dos mentes son mejores que una y, a menudo, alguien más pensará en algo que no hiciste (y viceversa).

Answer 6

Este sitio tiene una gran cantidad de recursos de ayuda para los códigos de prueba. SoftwareTestingHelp

Answer 7

Primero, debe asegurarse de que su código esté escrito para ser probado en unidades. Las dependencias de las clases externas deben ser explícitas (requeridas por el constructor si es posible) para que no sea posible escribir una prueba unitaria sin identificar todas las formas posibles de romper las cosas.Si encuentra que hay demasiadas dependencias, o que no es evidente cómo se usará cada dependencia, debe trabajar en el Principio de Responsabilidad Individual, que hará que sus clases sean más pequeñas, simples y más modulares.

Una vez que se escribe su código para que pueda prever situaciones que puedan ocurrir según sus dependencias y parámetros de entrada, debe escribir pruebas buscando el comportamiento correcto de una variedad de situaciones previsibles. Una de las mayores ventajas que he encontrado para las pruebas unitarias es que realmente me obligó a pensar, "¿y si ...?", Y averiguar cuál sería el comportamiento correcto en cada caso. Por ejemplo, tengo que decidir si tiene más sentido arrojar una excepción o devolver un valor nulo en el caso de ciertos errores.

Una vez que crea que tiene todas sus bases cubiertas, es posible que también desee arrojar su código a una herramienta como QuickCheck para ayudarlo a identificar las posibilidades que podría haber perdido.