2010-04-08 17 views
5

Acabo de leer el artículo Programming by Coincidence. Al final de la página hay ejercicios. Algunos fragmentos de código que son casos de "programación por coincidencia". Pero no puedo entender el error en esta pieza:'Programación por coincidencia' Ejercicio: Java File Writer

Este código proviene de un conjunto de aplicaciones de Java de propósito general . La función escribe una cadena en un archivo de registro. Es pasa su prueba de unidad, pero falla cuando uno de los desarrolladores web lo usa. ¿En qué se basa la coincidencia?

public static void debug(String s) throws IOException { 
    FileWriter fw = new FileWriter("debug.log", true); 
    fw.write(s); 
    fw.flush(); 
    fw.close(); 
    } 

Qué hay de malo en esto?

+0

¿No es el caso que las pruebas unitarias no garantizan un 100% de seguridad? Quiero decir, hay muchas coincidencias que enfrentamos los desarrolladores desde que comenzamos a programar :) – bragboy

+1

@Bragaadeesh: Esta es una prueba de unidad incorrecta porque viola el ["principio de responsabilidad única"] (http: //en.wikipedia .org/wiki/Single_responsibility_principle). Si está probando si el método registra correctamente la cadena, debe sacar la E/S del archivo. Debería recibir un 'java.io.Writer' creado desde otro lugar y escribir en él. –

Respuesta

10

Este código se basa en el hecho de que hay un archivo llamado debug.log que se puede escribir en el directorio de ejecución de la aplicación. Lo más probable es que la aplicación del desarrollador web no esté configurada con este archivo y el método falla cuando intenta usarlo.

Una prueba de unidad de este código funcionará porque el desarrollador original tenía el archivo correcto en el lugar correcto (y con los permisos correctos). Esta es la coincidencia que permitió que la prueba de la unidad tuviera éxito.

+0

Sí, iba a decir algo sobre los permisos. –

+0

Esto tiene sentido de hecho. Gracias por aclarar esto! –

0

Interesante tidbit. Idealmente, los recursos deben extraerse de la ruta de clase. Sin embargo, no hay ningún final para studpidity humano sin embargo. ¿Qué pasaría si el archivo estuviera presente en el classpath del entorno de prueba (por ejemplo, eclipse), pero faltara en las implementaciones de producción?

+0

Los recursos (si se refiere a los archivos, en el contexto de esta pregunta) no necesariamente se deben extraer de classpath. El programa no tiene que saber qué es classpath. Classpath es utilizado solo por el cargador de clases. Java no especifica un "directorio de trabajo" para el archivo IO. Es responsabilidad del programador pasar un directorio de trabajo a través de un argumento de línea de comando o, idealmente, un parámetro del sistema y usarlo en el programa. –

+0

Eso es lo que quise decir de manera ideal. Eso sería fácil para la migración a través de la plataforma, en lugar de la codificación. – Maddy