estoy familiarizado con los principios básicos de TDD, siendo:¿Cuál es el mejor enfoque para las pruebas unitarias cuando tiene interfaces con implementaciones ficticias y reales?
- pruebas de escritura, éstas fallarán debido a la falta de aplicación
- Escribir implementación básica para que pasen las pruebas
- código Refactor
Sin embargo, estoy un poco confundido acerca de dónde encajan las interfaces y la implementación. Estoy creando una aplicación web Spring en mi tiempo libre, y en lugar de ir en armas, me gustaría entender cómo puedo probar interfaces/implementaciones un poco mejor, tome este código de ejemplo simple que he creado aquí:
public class RunMe
{
public static void main(String[] args)
{
// Using a dummy service now, but would have a real implementation later (fetch from DB etc.)
UserService userService = new DummyUserService();
System.out.println(userService.getUserById(1));
}
}
interface UserService
{
public String getUserById(Integer id);
}
class DummyUserService implements UserService
{
@Override
public String getUserById(Integer id)
{
return "James";
}
}
he creado la interfaz UserService, en última instancia, habrá una aplicación real de este que va a consultar una base de datos, sin embargo, con el fin de conseguir la aplicación de la tierra que he sustituido una implementación DummyUserService que se acaba de regreso algunos datos estáticos por ahora.
Pregunta: ¿Cómo puedo poner en práctica una estrategia de ensayo de lo anterior?
que podría crear una clase de prueba llamada DummyUserServiceTest y la prueba de que cuando llamo getUserById() se volverá James, parece bastante simple si no es una pérdida de tiempo (?).
Posteriormente, yo también podría crear una clase de prueba RealUserService que probaría que getUserById() devuelve un nombre de usuario de la base de datos. Esta es la parte que me confunde levemente, al hacerlo, ¿no se sobrepasa el límite de una prueba unitaria y se convierte más en una prueba de integración (con el acierto en la base de datos)?
Pregunta (mejorado, un poco): Cuando se utilizan interfaces con dummy/stubbed, y las implementaciones reales, ¿qué partes deben probarse unitarias, y qué partes pueden dejarse sin probar?
pasé unas cuantas horas de buscar en Google sobre este tema anoche, y sobre todo encontrar ya sea tutoriales sobre lo que es TDD, o ejemplos de cómo utilizar JUnit, pero nada en los reinos de asesorar a lo que realmente debe hacerse la prueba. Sin embargo, es muy posible que no haya buscado lo suficiente o que no esté buscando lo correcto ...