Introducción
En algunos acentos del inglés, cuando dices «two for» rápido, suena como «two fer».
Two-for-one es una forma de decir que si compras uno, también te llevas otro gratis.
Así que la frase «two-fer» a menudo implica una oferta de dos por uno.
Imagina una panadería que tiene una oferta de temporada en la que puedes comprar dos galletas por el precio de una («two-fer one!»).
Aceptas la oferta y (con mucha generosidad) decides darle la galleta extra a otra persona en la fila.
Instrucciones
Tu tarea es determinar qué dirás al regalar la galleta extra.
Si sabes el nombre de la persona (por ejemplo, si se llama Do-yun), dirás:
One for Do-yun, one for me.
Si no sabes 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 entender cómo escribir código que pueda pasar los casos de prueba.
Para más contexto, revisa 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 quien programa a construir funcionalidad compleja poco a poco en lugar de hacerlo todo de una vez.
Ese ciclo se puede describir así:
- Agrega 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 agregada 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.
Esto normalmente implica renombrar variables, eliminar fragmentos de lógica duplicados, quitar registros que sobraron, etc.
- ¡Vuelve al paso 1 hasta que hayas construido toda la funcionalidad deseada!
Los archivos de prueba de este track contienen todas las pruebas que tu solución debe pasar para considerarse válida.
A primera vista, eso no parece ser compatible con el ciclo descrito arriba, en el que las pruebas se escriben una por 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 prueba que te entregamos cumplan las siguientes reglas:
- La primera prueba de cualquier archivo de prueba no se omite de forma predeterminada.
- Todas las pruebas excepto la primera de cualquier archivo de prueba se omiten de forma predeterminada.
Esto te permite simular el ciclo de TDD siguiendo estos pasos ligeramente modificados:
- Ejecuta las pruebas para verificar que como máximo una prueba falla en este momento.
- 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 prueba.
- ¡Vuelve al paso 1 hasta que no se omita ninguna prueba y todas pasen!
