Una herramienta importante para escribir aplicaciones de Android de calidad es un conjunto de pruebas unitarias automatizadas para probar su aplicación. Estas pruebas automatizadas tienen una serie de beneficios, entre ellos: Le obligan a comprender las funciones que está desarrollando. Hacer que una aplicación sea comprobable lo impulsa a tener una mejor arquitectura en su aplicación. Reducen la cantidad de tiempo que necesita dedicar a las pruebas de regresión manual. Le permiten realizar pruebas de regresión con frecuencia, lo que reduce los errores y detecta otros nuevos antes. Le brindan una herramienta para refactorizar su código sin miedo, ya que estará seguro de que no ha agregado errores. En este tutorial, modificarás un juego de trivia de cócteles agregándole pruebas unitarias. Las pruebas automatizadas implican varios tipos diferentes de pruebas además de las pruebas unitarias, así que primero observe cómo las pruebas unitarias encajan con otros tipos de pruebas. Las pruebas de pirámide de pruebas que puede incluir en el conjunto de pruebas de su aplicación se clasifican en tres categorías diferentes: Pruebas de interfaz de usuario: estas pruebas interactúan con la interfaz de usuario de su aplicación. Emulan el comportamiento del usuario y afirman los resultados de la interfaz de usuario. Estas son las pruebas más lentas y costosas que puede escribir porque requieren un dispositivo/emulador para ejecutarse. En Android, las herramientas más utilizadas para las pruebas de UI son Compose Test, Espresso y UI Automator. Pruebas de integración: utilícelas cuando necesite comprobar cómo interactúa su código con otras partes del marco de Android pero sin la complejidad de la interfaz de usuario. No requieren un dispositivo/emulador para ejecutarse. En Android, la herramienta más común para pruebas de integración es Robolectric. Pruebas unitarias: el sistema bajo prueba (SUT) es una clase y usted se concentra solo en ella. Se considera que todas las dependencias funcionan correctamente (e idealmente tienen sus propias pruebas unitarias :]), por lo que se burlan de ellas o se eliminan. Estas pruebas son las más rápidas y menos costosas que puede escribir porque no requieren un dispositivo/emulador para ejecutarse. En Android, las herramientas más utilizadas para pruebas unitarias son JUnit, Mockito y MockK. Como regla general, debe intentar dividir las siguientes categorías de pruebas en su proyecto: Pruebas de UI: 10% Pruebas de integración: 20% Pruebas unitarias: 70% Porque las habilidades necesarias para escribir pruebas unitarias proporcionan las habilidades fundamentales para escribir Pruebas de integración y UI, este tutorial se centrará en ellas. Nota: Este tutorial asume que tiene experiencia previa en el desarrollo para Android en Kotlin y que está familiarizado con el uso de las rutinas Compose y Kotlin. Si no estás familiarizado con el idioma, echa un vistazo a este tutorial. Si está comenzando con Android, consulte algunos de nuestros Primeros pasos y otros tutoriales de Android. Primeros pasos Descargue los materiales de este tutorial haciendo clic en el botón Descargar materiales en la parte superior o inferior del tutorial. Luego, abra el proyecto inicial en Android Studio Hedgehog o posterior. Trabajarás con un juego de preguntas sobre cócteles que muestra varios cócteles y te pide que adivines su nombre. Construye y ejecuta. Esto es lo que verá: El proyecto contiene varios componentes, entre ellos: MainActivity.kt: contiene la actividad principal de la aplicación. CocktailsComposable.kt: Contiene los elementos componibles para la aplicación. CocktailsViewModel.kt: ViewModel para vincular la vista al juego y los datos. Game.kt: contiene los datos del juego, así como algunos métodos de ayuda para realizar acciones en el juego. Ubicado en el juego ▸ modelo. Question.kt: contiene datos sobre una pregunta y tiene métodos abstractos para responder una pregunta. Ubicado en el juego ▸ modelo. Score.kt: Clase para mantener la puntuación e incrementarla cuando se responde correctamente una pregunta. Ubicado en el juego ▸ modelo. La aplicación final hará lo siguiente: Cargar una lista de cócteles de Internet. Genere preguntas a partir de esa lista y guárdelas en el objeto Juego. Recupere la primera pregunta y preséntela al usuario. Permita que el usuario seleccione cuál es la respuesta a qué cóctel cree que es. Incrementa la puntuación si la respuesta del usuario es correcta. Componentes que no debería realizar pruebas unitarias Lo primero que debe considerar al realizar pruebas es si un componente en el que está trabajando no puede o no debe someterse a pruebas unitarias. Si un componente cae en una de estas categorías, no es un buen candidato para las pruebas unitarias: tiene dependencias en el subsistema de Android. Tiene dependencias de un componente externo con una interfaz compleja. La lógica del componente no se puede trasladar a otro objeto que no dependa de los componentes de Android. En el proyecto inicial, tres archivos claramente se incluyen en estas categorías: MainActivyt.kt: una actividad está vinculada al ciclo de vida de la aplicación y al subsistema de Android. CocktailsApplication.kt: una clase de aplicación tiene muchas dependencias en el subsistema de Android. La incapacidad de realizar pruebas unitarias de la lógica en estos archivos es una de las razones por las que los buenos patrones de arquitectura recomiendan dividir la lógica en otros componentes. A medida que crea la funcionalidad en su aplicación, aprenderá acerca de los aspectos que hacen que un componente sea un buen candidato para probar. Escribir su primera prueba unitaria Obtener contexto Como primer paso, implementará la funcionalidad para mostrar una pregunta. Esta aplicación utiliza vistas de redacción. Abra el archivo CocktailsComposable.kt y observe lo que está haciendo. Contiene la interfaz completa que necesitará para su aplicación. Necesitará implementar la lógica en su modelo de vista para brindarle los datos que necesita. Mire en el medio de CocktailsScreen, el primer elemento componible del archivo, y verá: LaunchedEffect(Unit) { cocktailsViewModel.initGame() } Ese es el punto de entrada para su modelo de vista. Ahora, busque algunas líneas y verá esto: val question = cocktailsViewModel.question.collectAsState().value Esto obtiene una referencia a la pregunta actual en un StateFlow de CocktailsViewModel para usar en el resto de la pantalla. Ahora abra CocktailsViewModel. Actualmente, su modelo de vista no está haciendo mucho, pero ya se le han proporcionado algunas ayudas. Cada vez que juegas, se crea un nuevo objeto Juego. Abra el archivo Game.kt ubicado en el modelo del juego ▸. Las dos cosas importantes para su primera tarea son su lista de preguntas y su método de ayuda para obtener la siguiente pregunta que necesitará usar en su modelo de vista. nextQuestion() no está implementado actualmente, por lo que comenzarás a escribir una prueba unitaria para esto.

Source link