Pausa para el café #87. ¿Por qué son importantes las pruebas unitarias para los desarrolladores? 5 formas de copiar una matriz en Java

¿Por qué son importantes las pruebas unitarias para los desarrolladores?

Fuente: SearchSoftwareQuality Analicemos por qué las pruebas unitarias son importantes y valiosas, y cómo facilitan la depuración. Las pruebas unitarias son una herramienta poderosa para mejorar la calidad del software. Las pruebas unitarias proporcionan una verificación fundamental de que una aplicación cumple con las especificaciones del software y se comporta según lo previsto. Cuando se hace bien, las pruebas unitarias:

• reducir el número de defectos e identificarlos en las primeras etapas del ciclo de vida del desarrollo;
• mejorar la legibilidad del código;
• permitir la reutilización de código;
• aumentar la velocidad de implementación.

Veamos por qué las pruebas unitarias son importantes, cómo se originó este tipo de pruebas y cuáles son las barreras para su implementación.

Historia de las pruebas unitarias

Un error detectado a tiempo ahorra tiempo y esfuerzo. Durante los primeros 50 años de la historia de la informática, las pruebas unitarias y la depuración eran esencialmente lo mismo. Pero en la década de 1990, el código se había vuelto tan complejo que a menudo era imposible dividir el sistema en partes pequeñas para ejecutarlas de forma aislada. En 1997, un programador llamado Kent Beck creó JUnit, un complemento de entorno de desarrollo para probar pequeños fragmentos de código. El código de prueba que evalúa el código fuente se denomina pruebas unitarias. Este tipo de pruebas unitarias se ha convertido en un elemento básico durante muchos años. Después de que Beck creara JUnit, Martin Fowler escribió un libro, Refactoring, en el que propuso formas de transformar el código para hacerlo más aislado y comprobable. La combinación de refactorización de código y pruebas unitarias ha llevado al desarrollo basado en pruebas, donde la creación de pruebas unitarias es esencial para el proceso de programación. En él, el código debe poder comprobarse incluso antes de su creación. Por lo tanto, el proceso de programación no se completa hasta que se ejecutan las pruebas unitarias. Luego, el proyecto puede pasar a la etapa de investigación a nivel de sistemas o humano.

Ejemplo de prueba unitaria

Este ejemplo demuestra la importancia de las pruebas unitarias. Aquí JUnit evalúa una función simple que convierte la temperatura de Fahrenheit a Celsius. Fórmula de conversión: C = (F-32) * 5/9. Solo unas pocas líneas, incluida la firma de la función y las llaves, se pueden implementar en el código como una función de biblioteca. Sin embargo, de la función no se desprende claramente que se trate de criterios. Estas opciones pueden incluir redondeo hacia arriba o hacia abajo, números reales o límites superior e inferior. Creemos pruebas unitarias de ejemplo para esta función de conversión de temperatura en Perl usando el módulo Test::More. La primera línea es un comentario que le dice al programador qué esperar del código restante.

# is (input, expected result, comment)
is( FtoC(32),0,'Freezing point is F32, C 0');
is( FtoC(212),100,'Boiling point is F212, C 100');
is( FtoC(59038),32767, 'Upper limit of C is 32767');
is( FtoC(59039),undefined, 'One past upper limit is error');

El marco JUnit se basa en sistemas orientados a objetos y objetos de prueba, pero el concepto es similar.

Pruebas unitarias aisladas

Uno de los beneficios de las pruebas unitarias es que aíslan una función, clase o método y prueban solo ese fragmento de código. Mejores componentes individuales proporcionan resiliencia general del sistema. De esta manera obtendrás un código confiable. Las pruebas unitarias también cambian la naturaleza del proceso de depuración. Para intentar corregir un error, los programadores simplemente escriben una prueba fallida y luego la repiten para que pase sin violar las expectativas anteriores. Este proceso elimina el ciclo manual de depuración tradicional mediante configuración, recreación, pausa y prueba. Para cambiar el código y hacerlo adecuado para las pruebas unitarias, los programadores deben cambiar la forma en que trabajan. Cualquier fragmento de código escrito sin pruebas unitarias probablemente se considerará no probado, al menos como módulos individuales.

Adaptación de pruebas unitarias

El software heredado es software que se ha estado ejecutando durante mucho tiempo y probablemente se escribió sin pruebas unitarias. El código heredado tiene valor para la empresa. Funciona de manera estable durante muchos años. Algunos programas creados sin pruebas unitarias procesan transacciones de millones de dólares por día. Pero el código que no tiene pruebas unitarias se convierte en una gran bola de tierra con el tiempo porque ha sido tocado por muchos programadores de mantenimiento de código a lo largo de los años. La refactorización permite a los programadores realizar cambios gradualmente en un sistema para hacerlo comprobable. Sin embargo, estos cambios toman tiempo. Hace varios años, estuve discutiendo con mi colega Bob Reselman la cuestión del uso de pruebas unitarias para aplicaciones heredadas. Reselman argumentó que implementar pruebas unitarias en aplicaciones creadas sin ellas es demasiado costoso e incluso estúpido. En cambio, recomendó que la organización comenzara un nuevo desarrollo con pruebas unitarias y dejara las aplicaciones heredadas en paz. Esto puede ser cierto para COBOL, generadores de informes y otras aplicaciones, pero yo diría que en aplicaciones escritas en lenguajes modernos (C++, C#, Java y Ruby) es bastante fácil agregar pruebas unitarias de forma retroactiva. En lugar de escribirlas para toda la aplicación, simplemente agregue pruebas unitarias al cambio actual y refactorice a medida que avanza.

Mayor velocidad, calidad y capacidad de prueba.

Los directores de proyectos dicen que la planificación implica compensaciones entre calidad, cantidad de trabajo completado, recursos y tiempo. Para agregar algo a un área, debes quitar algo de otra. Las pruebas unitarias efectivas rompen esta regla. Es por eso que las pruebas unitarias son importantes y valiosas para las organizaciones. Las buenas pruebas unitarias producen código comprobable que mejora la calidad. Este código tendrá menos defectos, lo que significa menos correcciones de errores para completar el proyecto más rápido. Cuando el software encuentra errores, las pruebas unitarias aceleran la depuración, corrección y escritura de código. Y esto sucede de tal manera que la probabilidad de que un defecto vuelva a ocurrir se reduce significativamente y al mismo tiempo se mejora la calidad y la velocidad del código. Si bien no existe una fórmula mágica en el desarrollo de software, las pruebas unitarias efectivas pueden acelerar el desarrollo, las pruebas e incluso parte de la ingeniería de requisitos funcionales.

5 formas de copiar una matriz en Java

Fuente: Dev.to Entonces tienes dos matrices A y B y necesitas copiar los elementos de A a B. Bueno, hay diferentes maneras de hacer esto en Java y te las mostraré ahora.

Método uno: ForLoop

Aquí es donde el viejo bucle for viene en nuestra ayuda :

int[] A = {1,2,4,4};
int[] B = new int[];

 for (int i = 0; i < A.length; i++){
      B[i] = A[i];
}

Método dos: .clone()

El método de clonación de matrices también puede ayudar a lograr el resultado deseado:

int[] A = {1,2,4,4};
int[] B = A.clone();//the clone method copies the content of A into B;

Método tres: System.arraycopy()

La siguiente forma es utilizar el método System.arraycopy() , que se encuentra en el paquete java.lang . Antes de pasar a su uso, analicemos su firma:

public static void arraycopy(
    Object src, //:source array, in this case A
    int srcPos, //:the start index for copy, typically 0
    Object dest, //:destination object in this case B.
    int destPos, //:the index to place the copied elements
    int length //:the length of the contents to be copied
);

Solicitud:

int[] A = {1,2,4,4};
int[] B = new int[];

System.arraycopy(A, 0, B, 0, A.length);

Método cuatro: Arrays.copyOf()

La siguiente opción de copia que discutiremos es la clase Arrays del paquete java.utils . Presta atención a su firma:

public static int[] copyOf(
    int[] original, // :source array in this case A
    int newLength // :the length of the contents to be copied
);

Solicitud:

int[] A = {1,2,4,4};
int[] B = Arrays.copyOf(A, 3);

Método cinco: Arrays.copyOfRange()

Entonces, esta será la última opción que veremos en esta publicación. También es de la clase Arrays presente en el paquete java.utils . Miremos de nuevo su firma:

public static int[] copyOfRange​(
    int[] original, // :source array in this case A
    int from,  //:the start index for copy, typically 0
    int to // the end index exclusive
);

Solicitud:

int[] A = {1,2,3,4,5,6,7};
int[] B = Arrays.copyOfRange(A, 0, A.length);