Observaciones Técnicas

Aquí les detallo los puntos que consideramos que deberían tener en cuenta en cuanto a la presentación del proyecto y el uso del lenguaje el entorno de desarrollo.

Están etiquetadas por grado de severidad, siendo SEV1 la más importante, SEV4 sugerencia.

• Sev 2: No se deben subir archivos del entorno de desarrollo (*.suo, directorio obj, directorio bin)

• Sev 1: No se deben elegir nombres (directorios, archivos, clases, métodos, variables) que puedan resultar ofensivos. "FistBook" puede ser traducido como "Libro puño", que puede interpretarse de diversas maneras.

• Sev 2: El proyecto no compila sin modificaciones. Deben incluír las referencias como DLLs en un directorio, o proveer de las instrucciones para descargarlo (y un chequeo de precompilación). En el caso actual, indicar versión de NUnit y log4net a descargar.

• Sev 2: El código no cumple con la convención de código para .NET. Ejemplos de no cumplimientos: métodos que comienzan con minúscula, variables con notación húngara, variables de instancia sin modificador de protección. Se solicita usar stylecop para validar las convenciones.

Observaciones de Diseño y Desarrollo

Aquí detallo las observaciones referidas al diseño y programación. Las dividimos desde la perspectiva de los tests, porque es nuestro punto de entrada para la corrección.

TestFrontEnd:

• Sev1: El test suscribirYConfirmarUsuario no posee asserts, ni espera excepciones. No queda claro qué es lo que se desea probar porque falta justamente la condición. El hecho de que un método interno pueda llegar a arrojar alguna excepción en caso de error no nos ahorra tener que precisar qué es lo que estamos probando. Recordemos que la estructura de un test es SETUP-WORK-ASSERTS.

• Sev2: En confirmarSuscripcion nunca se elimina el usuario "potencial", de la lista de pendientes de confirmación.

• Sev4: No me pareció mal que hayan dividido en FrontEnd el método de búsqueda de usuario del de grupo. La posibilidad de la interfaz suscribible puede resultar cómoda a fines de consultas polimórficas, pero le quita legibilidad al código tratar las búsquedas como iguales, desde el punto de vista del cliente del método. Yo la dejaría como está.

TestUsuarios

• Sev3: No es muy útil testear un constructor como en el caso de construirUsuario. Asumimos que el usuario tiene que estar bien construido.

· Sev1: o me queda muy clara la distribución de responsabilidades en cuanto a que tanto etiquetar una foto, como agregarle un comentario son atribuciones del usuario, y, sin embargo, etiquetar aparece como método del usuario pero comentar directamente en foto. En el caso de la creación del grupo ocurre lo mismo. Sería interesante para este último pensar en un Builder, si bien como está hasta ahora cumple con lo pedido.

· Sev1: No están testeados todas las formas de aceptación de usuarios, y figuran como requerimientos.

TestGrupos

· Sev2: En método suscribirUsuario debería incluirse un test para indicar la situación en que se intenta suscribir a un usuario ya existente. El cliente del método nunca está al tanto de lo que sucede en estos casos.

Consideraciones Generales

· Sev2: Algunos requerimientos no están del todo bien implementados. Por ejemplo, se puede subir foto pero no se sabe bien quién la subió o a quién pertenecen.

· Sev1: Ciertos requerimientos no están testeados o no figuran en esta entrega:

- Cuando un usuario etiqueta a otro en una foto o deja un comentario en la misma, el sistema automáticamente envía un mensaje de parte del usuario etiquetador/comentador a todos los que estén etiquetados, todos los que hayan dejado comentarios y el que haya subido dicha foto. En caso que un mismo usuario haya hecho más de un comentario y/o sido etiquetado, solo debe recibir UN mensaje por cada acción realizada en la foto.

- Un usuario puede ver su inbox de mensajes, resaltándose aquellos que todavía no fueron leídos.

- Un usuario puede subir fotos.

- Un usuario puede ver las fotos que haya subido el mismo o uno de sus amigos, o las fotos en las que fue etiquetado.

Estos requerimientos deberían figurar en próximas entregas. Se sugiere enfocar el desarrollo a partir de los mismos, como se vio en clase con la técnica de TDD, y de esta forma no nos olvidamos de los objetivos principales del TP.

La entrega está aprobada.