Introducción
En algunos acentos del inglés, cuando dices «two for» muy rápido, suena como «two fer».
Dos por uno es una forma de decir que si compras uno, te llevas otro gratis.
Así que la expresión «two-fer» suele implicar una oferta de dos por uno.
Imagina una panadería que tiene una oferta de temporada en la que puedes comprar dos galletas al precio de una («two-fer one!»).
Aceptas la oferta y (muy generosamente) decides darle la galleta extra a otra persona de la cola.
Instrucciones
Tu tarea consiste en decidir qué vas a decir cuando regales la galleta extra.
Si conoces el nombre de la persona (por ejemplo, si se llama Do-yun), dirás:
One for Do-yun, one for me.
Si no conoces el nombre de la persona, en su lugar dirás you.
One for you, one for me.
Aquí tienes algunos ejemplos:
| Nombre |
Diálogo |
| Alice |
One for Alice, one for me. |
| Bohdan |
One for Bohdan, one for me. |
|
One for you, one for me. |
| Zaphod |
One for Zaphod, one for me. |
Implementación
Antes de empezar, asegúrate de que entiendes cómo escribir código que pueda superar los casos de prueba.
Para más contexto, echa un vistazo a este tutorial.
La mayoría de los ejercicios de Java incluyen varios casos de prueba.
Estos casos están estructurados para apoyar un proceso muy útil conocido como desarrollo guiado por pruebas (TDD).
El TDD consiste en repetir un ciclo estructurado que ayuda a los desarrolladores a construir funcionalidades complejas paso a paso en lugar de hacerlo todo de una vez.
Ese ciclo se puede describir así:
- Añade una prueba que describa una parte de la funcionalidad deseada que tu código todavía no tiene.
- Ejecuta las pruebas para verificar que esta prueba recién añadida falla.
- Actualiza tu código actual hasta que:
- Todas las pruebas anteriores sigan pasando;
- La nueva prueba también pase.
-
Limpia tu código, asegurándote de que todas las pruebas sigan pasando.
Normalmente, esto implica renombrar variables, eliminar fragmentos de lógica duplicados, eliminar los registros sobrantes, etc.
- Vuelve al paso 1 hasta que hayas construido toda la funcionalidad deseada.
Los archivos de pruebas de esta pista contienen todas las pruebas que tu solución debe superar para considerarse válida.
A primera vista, eso no parece compatible con el ciclo descrito antes, en el que las pruebas se escriben una a una.
Sin embargo, la herramienta que usamos para escribir nuestras pruebas, JUnit, ofrece una anotación @Disabled que se puede usar para omitir temporalmente una prueba ya escrita.
Con esta anotación, nos aseguramos de que los archivos de pruebas que te entregamos cumplan las siguientes reglas:
- La primera prueba de cualquier archivo de pruebas no se omite de forma predeterminada.
- Todas las pruebas de cualquier archivo de pruebas, salvo la primera, se omiten de forma predeterminada.
Esto te permite simular el ciclo de TDD siguiendo estos pasos ligeramente modificados:
- Ejecuta las pruebas para verificar que actualmente falla como máximo una prueba.
- Actualiza tu código actual hasta que pasen todas las pruebas no omitidas.
- Limpia tu código, asegurándote de que todas las pruebas no omitidas sigan pasando.
- Elimina la anotación
@Disabled que esté más arriba en el archivo de pruebas.
- Vuelve al paso 1 hasta que no se omita ninguna prueba y todas pasen.
