De Java a Kotlin

Capítulo 17. De los simulacros a los mapas

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Los mocks son una técnica común para desacoplar el código orientado a objetos de sus dependencias de producción. ¿Existen soluciones mejores en Kotlin?

Este es un breve capítulo adicional, continuación del capítulo 16. En ese capítulo, vimos que nuestras pruebas utilizaban simulacros porque tenían que implementar dos interfaces multimétodo, aunque la mayoría de esos métodos no se utilizaran. Dejamos la refactorización, habiendo sustituido las dependencias de interfaces multimétodo por una dependencia de sólo las dos operaciones que realmente se necesitaban para realizar la tarea. Las pruebas, sin embargo, siguen simulando toda la interfaz, y luego pasan una referencia a los métodos necesarios al sujeto bajo prueba (Recommendations):

public class RecommendationsTests {

    private final DistanceCalculator distanceCalculator =
        mock(DistanceCalculator.class);
    private final FeaturedDestinations featuredDestinations =
        mock(FeaturedDestinations.class);
    private final Recommendations recommendations = new Recommendations(
        featuredDestinations::findCloseTo,
        distanceCalculator::distanceInMetersBetween
    );
    ...
}

Ejemplo 17.1 [interfaces-to-funs.7:src/test/java/travelator/recommendations/RecommendationsTests.java] (diff)

Las pruebas abstraen la burla que hay detrás de los métodos givenFeaturedDestinationsFor y givenADistanceBetween