¿Proporcionando object burlado a otro constructor de object falso?

Prueba unitaria por primera vez y usando Mockito. No estoy seguro de si estoy pensando en probar esto correctamente. Aquí está la situación:

En mi aplicación de Android, estoy usando Model-View-Presenter. Estoy intentando probar un método en mi class de presentador llamado validateCnetworkingential(serviceManager: ServiceManager, email: String, password: String) para ver si el administrador de services que paso a él eventualmente llamará a una callback (este método es llamado por la vista) al verificarlo con mockito.

 // method in presenter class override fun validateCnetworkingential(serviceManager: ServiceManager, email: String, password: String) { loginModel = LoginModel(email, password) serviceManager.getParent(email, password) serviceManager.execute() } // callback implemented by presenter class private fun handleLoginResult(result: ServiceManager.RequestResult, data: ByteArray, responseCode: Int, optionalParam: String) { ... mView.startHomeScreen() } 

La class de presentador también implementa una interfaz de callback ( IServiceAsyncTaskCallback ) que se proporciona al constructor del IServiceAsyncTaskCallback . Lo que quiero en esta testing de unidad específica es verificar que se mView.startHomeScreen() .

El problema:

  • La testing de la unidad de Android parece requerir que se burla ServiceManager (ServiceManager amplía la class abstracta AsyncTask) porque cuando invoco execute() , la unit testing de Android lib lanzará una exception si no se burla.
  • Sin embargo, si me burlo del ServiceManager, no puedo proporcionarle dos parameters necesarios al constructor, lo cual DEBE burlarse, si entiendo las testings de la unidad correctamente. Los dos parameters para el constructor son una callback de interfaz (que es la class de presentador) y un object de class que es responsable de enviar JSON a través de http. Ambos deben ser burlados, ¿correcto? Porque en una testing de unidad no desea que estas dependencies realmente realicen llamadas HTTP o llamen a devoluciones de llamadas, ¿verdad?
  • Parece que estoy pensando demasiado en esto. Lo que realmente quiero es ver si mi object de vista que se pasa al presentador llama a startHomeScreen() , así que realmente debería olvidarme de probar validateCnetworkingentialMethod() y simplemente llamar a handleLoginResult(...) directamente. ¿Es esto mejor que la ruta anterior?
  • Sin embargo, otro problema es que incluso si llamo a handleLoginResult(...) directamente para probar si se llama a la vista simulada que se pasa al presentador, ese código de método contiene una llamada a JSONObject que es código relacionado con Android, y dado que pertenece a el file android.jar arrojará una exception porque no se burla! ¿Se supone que debo proporcionar una inyección para eso también?

Estoy perdido como para probar esto. ¿Cuál es la forma correcta de verificar que la vista simulada se ha llamado startHomeScreen() ?

El problema es que estás tratando de probar dos classs separadas en una testing unitaria, lo que hace que no sea una testing unitaria.

Con su configuration actual, parece que quiere tener 3 casos de testing diferentes, en 2 classs diferentes (devise nombres, tratando de ser lo más explícito posible sobre su contenido):

  • PresenterTest

    • testThatServiceManagerIsExcecutedOnValidateCnetworkingential
    • testThatStartHomeScreenIsCalledWhenHandlingLoginResult
  • ServiceManagerTest

    • testCallbackIsCalledOnExcecuted
  • ¿Cómo probar una class con un oyente anónimo que se establece dentro de una function?
  • Pruebas unitarias Rxjava observables que tienen un retraso
  • Solo la primera testing pasa con TestScheduler cuando se ejecutan varias testings (Kotlin)
  • Fallar las testings de la unidad kotlin después del plugin de gradle 3.0
  • La cobertura de código de estudio de Android no muestra ninguna class de Kotlin
  • El resultado es el mismo, pero el caso de testing no pasa en la testing unitaria
  • ¿Cómo un código de testing unitaria envuelto en `runOnUiThread`?
  • Calculadora simple, testing unitaria usando KOTLIN con Spek (código de salida -1)
  • cómo acceder a las properties internas desde el código de testing java
  • Prueba unitaria de la function de extensión de Kotlin en las classs de Android SDK
  • Unidad de testing Room y LiveData