Pruebas de integración para verificar pérdidas de memoria

Escribimos muchas pruebas unitarias, desarrollando la aplicación SoundCloud para iOS. Las pruebas unitarias se ven bastante hermosas. Son cortos, (con suerte) legibles, y nos dan la confianza de que el código que escribimos funciona como se esperaba. Pero las pruebas unitarias, como su nombre lo indica, cubren solo un bloque de código, la mayoría de las veces una función o clase. Entonces, ¿cómo detecta los errores que existen en las interacciones entre clases, errores como pérdidas de memoria ?

Fugas de memoria

A veces es bastante difícil detectar un error de pérdida de memoria. Existe la posibilidad de una fuerte referencia al delegado, pero también hay errores que son mucho más difíciles de detectar. Por ejemplo, ¿es obvio que el siguiente código puede contener una pérdida de memoria?

final class UseCase { weak var delegate: UseCaseDelegate? private let service: Service init(service: Service) { self.service = service } func run() { service.makeRequest(handleResponse) } private func handleResponse(response: ServiceResponse) { // some business logic and then... delegate.operationDidComplete() } } 

Dado que el Servicio ya se está implementando, no hay garantías con respecto a su comportamiento. Al pasar la función handleResponse a una función privada, que se captura a sí misma , proporcionamos al Servicio una fuerte referencia a UseCase . Si el Servicio decide mantener este enlace, y no tenemos garantía de que esto no suceda, se produce una pérdida de memoria. Pero con un estudio superficial del código, no es obvio que esto realmente pueda suceder.

También hay una publicación maravillosa de John Sandell sobre el uso de pruebas unitarias para detectar pérdidas de memoria para las clases. Pero con el ejemplo anterior, donde es muy fácil omitir una pérdida de memoria, no siempre está claro cómo escribir una prueba unitaria de este tipo. (Por supuesto, no estamos hablando aquí en términos de experiencia).

Como escribió Guilherme en una publicación reciente , las nuevas características de la aplicación SoundCloud para iOS están escritas de acuerdo con "patrones arquitectónicos limpios"; con frecuencia, este es un tipo de VIPER . La mayoría de estos módulos VIPER se crean utilizando lo que llamamos ModuleFactory . Tal ModuleFactory toma algunas entradas, dependencias y configuración, y crea un UIViewController que ya está conectado al resto del módulo y se puede insertar en la pila de navegación.

Este módulo VIPER puede tener varios delegados, observadores y fallas fuera de control, cada una de las cuales puede hacer que el controlador permanezca en la memoria después de que se retira de la pila de navegación. Cuando esto sucede, la cantidad de memoria aumentará y el sistema operativo puede decidir detener la aplicación.

Entonces, ¿es posible cubrir tantas fugas potenciales escribiendo tan pocas pruebas unitarias como sea posible? Si no, entonces todo esto fue una gran pérdida de tiempo.

Pruebas de integración

La respuesta, como habrás adivinado por el título de esta publicación, es sí. Y lo hacemos a través de pruebas de integración. El propósito de la prueba de integración es probar cómo los objetos interactúan entre sí. Por supuesto, los módulos VIPER son grupos de objetos, las pérdidas de memoria son una forma de interacción que definitivamente queremos evitar.

Nuestro plan es simple: vamos a utilizar nuestro ModuleFactory para crear una instancia de un módulo VIPER . Luego, eliminaremos el enlace al UIViewController y nos aseguraremos de que todas las partes importantes del módulo se destruyan junto con él.

El primer problema que enfrentamos es que, por naturaleza, no podemos acceder fácilmente a ninguna parte del módulo VIPER que no sea UIViewController . La única función pública en nuestro ModuleFactory es func make () -> UIViewController . Pero, ¿qué pasa si agregamos otro punto de entrada solo para nuestras pruebas? Este nuevo método se declarará a través de interno , por lo que solo podemos acceder a él a través de la importación @testable , el framework ModuleFactory . Devolverá enlaces a todas las partes más importantes del módulo, que luego podríamos mantener para que los enlaces débiles ingresen en nuestra prueba. En última instancia, se ve así:

 public final class ModuleFactory { //     ,   ... public func make() -> UIViewController { makeAndExpose().view } typealias ModuleComponents = ( view: UIViewController, presenter: Presenter, Interactor: Interactor ) func makeAndExpose() -> ModuleComponents { // Set up code, and then... return ( view: viewController, presenter: presenter, interactor: interactor ) } } 

Esto resuelve el problema de la falta de acceso directo a los datos del objeto. Obviamente, esto no es ideal, pero satisface nuestras necesidades, así que pasemos a escribir la prueba. Se verá así:

 final class ModuleMemoryLeakTests: XCTestCase { //      .     //    . private var view: UIViewController? //        //   ,    // UIKit,   UIViewController  . private weak var presenter: Presenter? private weak var interactor: Interactor? //   setUp    ModuleFactory  //   makeAndExpose.     ,   //     ModuleComponents // ,          . //     . func setUp() { super.setUp() let moduleFactory = ModuleFactory(/* mocked dependencies & config */) let components = moduleFactory.makeAndExpose() view = components.view presenter = components.presenter interactor = components.interactor } //   ,   tearDown   , //        ,     ,   //     . func tearDown() { view = nil presenter = nil interactor = nil super.tearDown() } func test_module_doesNotLeakMemory() { //   ,      . //      ,  //          setUp. XCTAssertNotNil(presenter) XCTAssertNotNil(interactor) //        . //    ,   //     ,    //      . view = nil // ,  ,    //  Presenter  Interactor   . //  ,       //  ,    . XCTAssertNil(presenter) XCTAssertNil(interactor) } } 

Entonces, tenemos una manera fácil de detectar pérdidas de memoria en el módulo VIPER . De ninguna manera es ideal y requiere un cierto trabajo del usuario para cada módulo nuevo que queremos probar, pero esto es ciertamente mucho menos trabajo que escribir pruebas unitarias separadas para cada posible pérdida de memoria. También ayuda a identificar pérdidas de memoria que ni siquiera sospechamos. De hecho, después de escribir varias de estas pruebas, se reveló que tenemos una prueba que no pasa, y después de algunas investigaciones, encontramos una pérdida de memoria en el módulo. Después de la corrección, la prueba debe repetirse.

También nos da un punto de partida para escribir un conjunto más general de pruebas de integración para módulos. Al final, si solo mantenemos un vínculo fuerte con el Presentador y reemplazamos el UIViewController con simulacro , podemos falsificar la entrada del usuario, luego invocar los métodos del presentador y verificar la visualización ficticia de los datos en la Vista .