Introducción
Después de años rellenando formularios y esperando, por fin has conseguido tu licencia bancaria.
Esto significa que ahora puedes abrir oficialmente tu propio banco, ¡hurra!
Tu primera prioridad es poner en marcha los sistemas informáticos.
Después de un día de duro trabajo, ya puedes abrir y cerrar cuentas, además de gestionar ingresos y reintegros.
Como no tenías ganas de escribir tests, invitas a unos amigos para que te ayuden a probar el sistema.
Sin embargo, a los cinco minutos, uno de tus amigos afirma que ha perdido dinero.
Aunque confías en que tu código no tiene errores, empiezas a revisar los registros para investigar.
Ah, sí, justo como sospechabas, ¡tu amigo tiene la culpa!
Compartió sus credenciales de prueba con otro amigo y, juntos, conspiraron para hacer ingresos y reintegros desde la misma cuenta en paralelo.
¿A quién se le ocurriría hacer algo así?
Mientras argumentas que es físicamente imposible que alguien acceda a su cuenta en paralelo, tu amigo te informa con suficiencia de que las normas bancarias exigen que lo soportes.
Así que, sin soporte para la banca en paralelo, no hay señal de lanzamiento.
Suspiras y te apuntas mentalmente que mañana te pondrás con ello.
Esto retrasará tu fecha de lanzamiento al menos un día más, pero bueno...
Instrucciones
Tu tarea consiste en implementar cuentas bancarias que admitan aperturas y cierres, retiradas e ingresos de dinero.
Como se puede acceder a las cuentas bancarias de muchas maneras distintas (internet, teléfonos móviles, cargos automáticos), tu software bancario debe permitir acceder a las cuentas de forma segura desde varios hilos o procesos en paralelo (la terminología depende de tu lenguaje de programación).
Por ejemplo, puede haber muchos ingresos y retiradas ocurriendo en paralelo; debes asegurarte de que no haya condiciones de carrera entre el momento en que lees el saldo de la cuenta y aquel en que estableces el nuevo saldo.
Debe ser posible cerrar una cuenta; las operaciones sobre una cuenta cerrada deben fallar.
Python no admite la concurrencia «verdadera» debido al Global Interpreter Lock.
Mientras se trabaja en dar compatibilidad con el free-threading en Python, este sigue siendo experimental.
Las soluciones actuales de la biblioteca estándar, como multiprocessing y threading, son difíciles de implementar con las herramientas actuales del track.
Por consiguiente, el requisito de concurrencia se ha dejado de lado en este ejercicio.
Las operaciones de la cuenta son secuenciales en un único hilo, y no se ejecuta ninguna prueba de concurrencia ni de «condición de carrera».
Si quieres experimentar con el free-threading o con las pruebas de concurrencia, te pedimos que lo hagas en local.
Para obtener ayuda sobre cómo descargar ejercicios y trabajar con ellos en local, te recomendamos la Exercism CLI.
Mensajes de excepción
A veces es necesario lanzar una excepción. Cuando lo hagas, siempre deberías incluir un mensaje de error significativo que indique cuál es el origen del error. Esto hace que tu código sea más legible y ayuda mucho a la hora de depurar. Para situaciones en las que sabes que el origen del error será de un tipo concreto, puedes optar por lanzar uno de los tipos de error integrados, pero aun así deberías incluir un mensaje significativo.
Este ejercicio en concreto requiere que uses la instrucción raise para «lanzar» un ValueError cuando una cuenta esté abierta o no lo esté, o cuando las cantidades de retirada o ingreso no sean correctas. Las pruebas solo pasarán si lanzas la exception con raise e incluyes un mensaje con ella.
Para lanzar un ValueError con un mensaje, escribe el mensaje como argumento del tipo exception:
# account is not open
raise ValueError('account not open')
# account is already open
raise ValueError('account already open')
# incorrect withdrawal/deposit amount
raise ValueError('amount must be greater than 0')
# withdrawal is too big
raise ValueError('amount must be less than balance')
