La idea de este auxiliar práctico es poner en práctica todo lo que es Test Driven Development (TDD)
Ustedes trabajan para una famosa red social llamada T***ter que recientemente ha cambiado de dueño. Es nuevo CEO quiere rehacer todo de nuevo y asegurarse que todo este bien diseñado.
- Cree la clase
SocialYdentro del paquete social, OJO, esta clase NO debe extender del traitISocialY, eso será una Mousekeherramienta que nos servirá más tarde. - Esta clase debe incluir los siguientes métodos:
def login(username: String, password: String): Boolean
def register(username: String, password: String): BooleanRecuerde que debe hacerlo siguiendo TDD: primero los tests y luego el código. La recomendación es crear la clase SocialY pero dejarla en blanco y luego crear la clase SocialYTest en el paquete de testing correspondiente y hacer que extienda de FunSuite de Munit.
Para ello debe guiarse de los siguientes requisitos:
login- un usuario debe poder loggearse.
- un usuario que no existe no debe poder loggearse.
- un usuario solo puede loggearse si su contraseña es correcta.
register- un usuario debe poder registrarse.
- un nueve usuario no puede ocupar un
usernameen uso.
Hint: Puede usar la clase Map (diccionario) de Scala para guardar los username con sus respectivas password
Al señor Alon (el dueño) parece gustarle su manera de trabajar, asi que como regalo le asignó más trabajo!
Ahora debe crear la clase User que representa un usuario dentro de la red social “Y”, para ello esta vez SI haga que este implemente el trait IUser.
Al extender un trait, la clase debe si o si implementar ciertas funcionalidades. Son justamente estas las que usted tiene que testear primero y luego implementar, de manera similar, debe crear la clase UserTest primero y hay hacer testing.
Los requisitos son los siguientes:
- Se debe poder saber la cantidad de seguidores y seguidos de un usuario
- Es obligatorio que el usuario tenga username y password
- Es opcional que el usuario tenga name (es decir, que debe haber un valor por defecto)
- Un usuario puede seguir a multiples usuarios
- Un usuario puede ser seguido por multiples usuarios
- Un usuario puede dejar de seguir a un usuario que siga
- Un usuario no puede seguirse a sí mismo
- No se puede seguir(dejar de seguir) dos veces al mismo usuario
- La contraseña debe ser secreta, por lo que debe haber una forma de autenticar un posible intento de login
Hint: Puede usar la clase Set de Scala para guardar los seguidores y seguidos de manera única
Un trabajo simplemente impecable, todos en la empresa están maravillados con usted, solo falta la última patita: Arreglar SocialY.
Ahora que tiene IUser bien implementado, arregle SocialY, haciendo que implemente el trait ISocialY, si se fija las únicas diferencias es que ahora deben retornar un Option[IUser].
Extienda "a la mala" Social usando ISocialY, cambiando el valor de retorno correspondiente. Recuerde que la gracia de Option es que puede retornar None o Some, es decir, nulo o algo. Si se fija el método get de un Map usa justamente esto puesto que la llave puede o no estar en el diccionario.
Para este caso login funciona de manera muy similar: buscando un User en el Map y retornandolo con las debidas precauciones. Para el caso del register se debe crear el User dentro del método y agregarlo a la memoria, luego retornar, de nuevo, con las debidas precauciones.
Hint: En los tests en vez de usar el retorno de las funciones (true or false) use el método isDefined de Option.
Dado el reciente nuevo publico hay demasiados usuarios mal portados.
Para lo cual su querido jefe le asigna su última tarea añadir usuarios Admin.
Que no se olvide: Siempre TDD.
Requisitos:
- Un admin debe de poder establecer el estado de un usuario a “Muted” o “Banned”
- Un admin debe de poder quitar cualquiera de la restricciones impuestas a un usuario
- Un admin también tiene username
- Los administradores no se deberían poder cambiar el estado entre ellos
Hint: No sea reacio a cambiar código anterior al añadir cosas nuevas