La cantidad de inter\u00e9s mostrado en Flutter ha alcanzado un m\u00e1ximo hist\u00f3rico, lo que es tanto bienvenido como necesario desde hace tiempo. Android, iOS, macOS, web, Windows y Linux son todos compatibles con el kit de desarrollo de software (SDK) de c\u00f3digo abierto de Google. Todos estos est\u00e1n soportados por una \u00fanica base de c\u00f3digo para Flutter. Y las pruebas unitarias son esenciales para proporcionar un programa Flutter que sea confiable y consistente. Esta prueba protege la aplicaci\u00f3n de errores, fallas y otro tipo de defectos al mejorar de manera proactiva la calidad del c\u00f3digo antes de que se ensamble.<\/p>\n
El proceso de revisar y verificar que una aplicaci\u00f3n de software hace lo que est\u00e1 destinada a hacer se conoce como prueba automatizada de software. Elimina errores y reduce el coste general de desarrollo.<\/p>\n
Para entender, hay algo que necesita ser comprendido. El \u00fanico prop\u00f3sito de las pruebas automatizadas es evitar que el software tenga errores ya predeterminados. No significa que el software est\u00e9 completamente libre de errores o fallos. Simplemente denota que el software no incluye errores t\u00edpicos.<\/p>\n
Tras la fase de desarrollo, pasamos a escribir los casos de prueba esperados (TDD es una excepci\u00f3n). En la mayor\u00eda de las circunstancias, enviaremos el software una vez que haya pasado con \u00e9xito todos los casos de prueba. Sin embargo, supongamos que se descubre un error mientras el software se est\u00e1 utilizando en producci\u00f3n. En ese caso, lo corregiremos y luego escribiremos los casos de prueba para evitar que el software incluya el mismo error en el futuro.<\/p>\n
La prueba no es m\u00e1s que el acto de verificar algo. Al desarrollar una nueva caracter\u00edstica o reparar un error existente, los casos de prueba nos ayudan a determinar si todas las caracter\u00edsticas y unidades implementadas previamente funcionan como se pretende. Garantiza que el desarrollo en curso no comprometer\u00e1 ninguna de las funciones que ya est\u00e1n en su lugar.<\/p>\n
“La prueba demuestra que hay errores, no que no los hay. \u2014 Edsger Dijkstra<\/p>\n
La prueba unitaria se implementa en Flutter de una manera muy similar a como se implementa en otras pilas tecnol\u00f3gicas. En Flutter, sigues los siguientes procesos:<\/p>\n
Analizar el c\u00f3digo.<\/p>\n<\/li>\n
Configurar la simulaci\u00f3n de datos (mocking).<\/p>\n<\/li>\n
Definir la prueba para el grupo(s).<\/p>\n<\/li>\n
Definir la firma de la funci\u00f3n de prueba (o firmas) para cada grupo de prueba.<\/p>\n<\/li>\n
Escribir las pruebas.<\/p>\n<\/li>\n<\/ol>\n
El proceso de prueba automatizada incluye un paso probado como “prueba unitaria”, que verifica la confiabilidad de fragmentos de c\u00f3digo m\u00e1s peque\u00f1os ejecut\u00e1ndolos a trav\u00e9s de varios casos de uso. Una unidad puede ser cualquier cosa, desde una variable hasta una funci\u00f3n, un m\u00e9todo, una clase o un estado.<\/p>\n
El primer y m\u00e1s fundamental nivel de prueba se llama prueba unitaria. En este nivel, probamos la funcionalidad de los componentes subyacentes de cada caracter\u00edstica.<\/p>\n
Una prueba unitaria se compone de tres etapas:<\/p>\n
Organizar (Arrange)<\/strong><\/p>\n<\/li>\n Actuar (Act)<\/strong><\/p>\n<\/li>\n Afirmar (Assert)<\/strong><\/p>\n<\/li>\n<\/ul>\n Lo que debe hacerse durante la fase de Organizar es establecer el objeto de la unidad que necesita ser probada y preparar los prerrequisitos para nuestra prueba. Estas preparaciones incluyen configurar la variable de estado y simulaciones (mocks), entre otras cosas. Por supuesto, dependiendo de los requisitos, la fase de Organizar podr\u00eda no ser necesaria en absoluto.<\/p>\n Durante la fase de Actuar, ponemos a prueba la unidad pasando argumentos y modificando alg\u00fan estado antes de almacenar el resultado, si lo hay.<\/p>\n Durante el paso de Afirmar, verificamos si la unidad se comporta como anticipar\u00edamos. Por ejemplo, podr\u00edamos anticipar que se llamar\u00e1 a un m\u00e9todo determinado, o que el resultado ser\u00e1 el mismo que lo que se anticip\u00f3.<\/p>\n Escribir y ejecutar pruebas unitarias es un proceso simple. Esto resulta en un ahorro de tiempo significativo.<\/p>\n<\/li>\n A trav\u00e9s de las pruebas unitarias, podemos descubrir errores en una etapa m\u00e1s temprana. Esto resulta en un ahorro significativo de costos y tiempo.<\/p>\n<\/li>\n Debido a que escribimos sobre todos los resultados posibles de la unidad, es f\u00e1cil para todos entender de qu\u00e9 se trata la unidad. Como resultado, esto da lugar a una documentaci\u00f3n mejorada.<\/p>\n<\/li>\n Debido a que hacerlo podr\u00eda hacer que la unidad se vuelva inutilizable, no refactorizamos tu c\u00f3digo con demasiada frecuencia. En cambio, la presencia de pruebas unitarias nos da la confianza necesaria para retrabajar nuestro c\u00f3digo.<\/p>\n<\/li>\n La depuraci\u00f3n es sencilla. Dado que tenemos conocimiento completo de las situaciones fallidas, podemos centrarnos en la unidad espec\u00edfica que es la ra\u00edz del error.<\/p>\n<\/li>\n Simplemente al mirar los casos de prueba obtenemos una imagen clara de lo que la unidad est\u00e1 destinada a entender. Como resultado, el mantenimiento a largo plazo se simplifica.<\/p>\n<\/li>\n<\/ul>\n Para construir un conjunto confiable de pruebas unitarias, primero debemos comprender los elementos que deben ser validados dentro de cada unidad individual.<\/p>\n La prueba unitaria a menudo se concentra en los siguientes elementos:<\/p>\n Variables de estado<\/p>\n<\/li>\n Llamadas a funciones\/variables<\/p>\n<\/li>\n Los argumentos de la funci\u00f3n<\/p>\n<\/li>\n Retornos de funciones<\/p>\n<\/li>\n<\/ul>\n Las variables que pertenecen al estado son variables que existen fuera del \u00e1mbito local. Esto puede ser una propiedad de clase o una variable global a la que m\u00e1s de una unidad puede acceder. En la mayor\u00eda de los casos, mantiene un estado.<\/p>\n En una unidad, vigilamos los siguientes escenarios, entre otros:<\/p>\n Verificar si el valor de la constante o la variable final es correcto.<\/p>\n<\/li>\n Valores al inicio de las variables de estado.<\/p>\n<\/li>\n Verificar si una funci\u00f3n particular es llamada 1…n veces por la unidad.<\/p>\n<\/li>\n Verificar si la unidad nunca llama a una funci\u00f3n particular.<\/p>\n<\/li>\n Verificar que las variables de estado se est\u00e9n actualizando de la manera que anticipas.<\/p>\n<\/li>\n El resultado de la unidad fue exactamente el mismo que lo que se anticip\u00f3.<\/p>\n<\/li>\n Aseg\u00farate de verificar situaciones vac\u00edas whenever una cadena, lista o cualquier otro tipo de estructura de datos (DS) compleja est\u00e9 involucrada; esto es especialmente importante cuando recorremos la DS.<\/p>\n<\/li>\n Verificar casos de nulo (Solo para tipos que pueden ser nulos). Dart es ahora seguro contra nulos.<\/p>\n<\/li>\n Verificar el tipo de la variable o el argumento (aunque esto puede no ser necesario si usamos efectivamente el sistema de tipos de Dart).<\/p>\n<\/li>\n<\/ul>\n Cuando se forma un proyecto, el proceso de prueba se simplifica gracias al marco gracias a la carga autom\u00e1tica de la biblioteca\u00a0 Estableceremos un \u00e1rea de almacenamiento ordenada para los archivos de prueba que escribiremos, un sistema en el que diferentes grupos de pruebas tendr\u00e1n cada uno sus “hogares” que son inmediatamente reconocidos. En vista de la necesidad impuesta por Flutter de ubicar las pruebas dentro de la carpeta\u00a0 Adoptar este formato de archivo trae transparencia al proyecto. Proporciona al grupo un m\u00e9todo sencillo para determinar qu\u00e9 partes de nuestro c\u00f3digo tienen pruebas correspondientes.<\/p>\n Las pruebas unitarias necesitan ser r\u00e1pidas.<\/p>\n<\/li>\n Las pruebas unitarias deber\u00edan ser sencillas.<\/p>\n<\/li>\n Las pruebas unitarias deber\u00edan ser predeterminadas.<\/p>\n<\/li>\n El \u00e9nfasis debe colocarse en las pruebas unitarias.<\/p>\n<\/li>\n En las pruebas unitarias, es aceptable repetir c\u00f3digo.<\/p>\n<\/li>\n La descripci\u00f3n de la prueba debe ser sencilla.<\/p>\n<\/li>\n<\/ul>\n Las pruebas unitarias deben ser r\u00e1pidas.<\/strong>\u00a0Debido a que ejecutaremos todo el conjunto de pruebas nosotros mismos a lo largo de la fase de desarrollo, cada prueba unitaria en nuestro conjunto de pruebas deber\u00eda poder ejecutarse en menos de un minuto. Esto ayuda en la detecci\u00f3n y correcci\u00f3n temprana de errores. Si toma m\u00e1s tiempo, normalmente incorporaremos esa tarea en una canalizaci\u00f3n de alg\u00fan tipo.<\/p>\n Las pruebas unitarias deber\u00edan ser sencillas.<\/strong>\u00a0Cuando revisamos un caso de prueba unitario, toda la informaci\u00f3n requerida debe estar contenida dentro de ese caso de prueba. No es aceptable que naveguemos el c\u00f3digo para entender una sola prueba. Por lo tanto, la prueba unitaria no deber\u00eda requerir una explicaci\u00f3n.<\/p>\n El determinismo debe aplicarse a las pruebas unitarias.<\/strong>\u00a0Sin hacer ning\u00fan cambio al c\u00f3digo fuente, una prueba unitaria siempre deber\u00eda replicar exactamente el mismo comportamiento sin importar d\u00f3nde o cu\u00e1ndo se pruebe. Los resultados de una prueba unitaria no deber\u00edan depender de variables o condiciones externas, como la hora actual, una base de datos, la web o una API nativa. En la mayor\u00eda de los casos, nos burlamos de ellos (usamos mocks).<\/p>\n El enfoque debe estar en las pruebas unitarias.<\/strong>\u00a0Una sola unidad deber\u00eda servir como el \u00fanico foco de una prueba unitaria. Dentro del contexto de la prueba unitaria, no deber\u00edamos probar las dependencias.<\/p>\n En las pruebas unitarias, es aceptable repetir c\u00f3digo.<\/strong>\u00a0El objetivo de una prueba unitaria deber\u00eda ser asegurar que el c\u00f3digo que se est\u00e1 probando sea lo m\u00e1s sencillo posible. Deber\u00eda ser posible para cualquiera entender el caso de prueba sin la necesidad de investigar sus dependencias o el estado presente de la unidad. Por lo tanto, repetir ciertos fragmentos de c\u00f3digo es aceptable si hacerlo hace el programa m\u00e1s f\u00e1cil de comprender y m\u00e1s sencillo.<\/p>\n La descripci\u00f3n de la prueba unitaria debe ser sencilla.<\/strong>\u00a0Una buena descripci\u00f3n debe contener cuatro partes:<\/p>\n La unidad que se pondr\u00e1 a prueba.<\/p>\n<\/li>\n La condici\u00f3n en la que se encuentra la unidad en el momento.<\/p>\n<\/li>\n La contribuci\u00f3n que haremos.<\/p>\n<\/li>\n La reacci\u00f3n que estamos preparando.<\/p>\n<\/li>\n<\/ol>\n El objetivo principal de las pruebas unitarias es compartimentalizar y enfocarse en la unidad que est\u00e1 siendo evaluada en lugar de concentrarse en probar cualquier otra dependencia que pueda estar presente. Sin embargo, en la mayor\u00eda de las circunstancias, debemos confiar en otras dependencias como servidores de bases de datos, servidores web, APIs de plataforma y otros dispositivos y componentes externos.<\/p>\n Supongamos por un momento que nuestra unidad actual es dependiente de una API web. La prueba se completa lentamente pero con \u00e9xito cuando se ejecuta en un servidor en vivo. Sin embargo, la prueba unitaria fallar\u00e1 si el servidor no est\u00e1 disponible. Esto resulta en impredictibilidad en la prueba unitaria. Porque ya no tendremos control sobre el servidor web. Cuando el servidor web experimenta una interrupci\u00f3n, no es nuestra culpa. El uso de la simulaci\u00f3n (mocking) ocurre en este punto.<\/p>\n En el contexto de las pruebas unitarias, “simular” (mocking) se refiere al proceso que se lleva a cabo cada vez que la unidad que se est\u00e1 probando depende de recursos externos. La simulaci\u00f3n se usa para aislar y concentrarse en el c\u00f3digo que se est\u00e1 probando en lugar de en el comportamiento de cualquier dependencia externa.<\/p>\n El objetivo principal de Mocktails es proporcionar una API sencilla y conocida para el desarrollo de simulaciones (mocks) en Dart, completa con seguridad de nulos, sin requerir la creaci\u00f3n manual de simulaciones o la generaci\u00f3n de c\u00f3digo.<\/p>\n Felix Angelov, la misma persona que produjo bloc, equatable y otros programas similares, es el autor de esta librer\u00eda. A\u00fan m\u00e1s impresionante que sus otros paquetes es el hecho de que esta librer\u00eda tiene una cobertura completa de su c\u00f3digo.<\/p>\n \u00bfEn Flutter, qu\u00e9 es una Prueba Unitaria?<\/strong><\/p>\n Las pruebas unitarias son muy \u00fatiles cuando se verifica el funcionamiento de un \u00fanico m\u00e9todo, clase o funci\u00f3n. El paquete\u00a0 \u00bfCu\u00e1ntos tipos de pruebas unitarias admite el framework Flutter?<\/strong><\/p>\n Tres tipos distintos de pruebas pueden ejecutarse con Flutter. Primero, la operaci\u00f3n de un m\u00e9todo o clase es validada por una prueba unitaria. Sin ejecutar realmente la aplicaci\u00f3n en s\u00ed, la funcionalidad de los widgets de Flutter puede ser validada con el uso de una prueba de widget. Finalmente, toda la aplicaci\u00f3n se somete a lo que se conoce como una prueba de integraci\u00f3n, que tambi\u00e9n se conoce como prueba de extremo a extremo o prueba GUI.<\/p>\n \u00bfEn Flutter, qu\u00e9 se necesita para crear una prueba unitaria?<\/strong><\/p>\n El proceso para realizar pruebas unitarias en Flutter es id\u00e9ntico al procedimiento que se usa en la mayor\u00eda de otros marcos. Despu\u00e9s de establecer las clases y funciones que necesitan ser probadas (los casos de prueba), el siguiente paso es evaluar el c\u00f3digo, configurar la simulaci\u00f3n de datos (mocking), definir los grupos de prueba, definir las firmas de las funciones de prueba para cada grupo de prueba, escribir las pruebas y ejecutarlas.<\/p>\n \u00bfPor qu\u00e9 es vital realizar pruebas unitarias?<\/strong><\/p>\n Las pruebas unitarias pueden eliminar o reducir significativamente la cantidad de errores en una aplicaci\u00f3n, lo que resulta en una experiencia de usuario mejorada desde el momento en que una aplicaci\u00f3n est\u00e1 disponible para el p\u00fablico. Adem\u00e1s, leer pruebas unitarias es una forma excelente de ayudar a los nuevos desarrolladores a aprender y entender tu c\u00f3digo, lo que es un beneficio adicional.<\/p>\n","protected":false},"excerpt":{"rendered":" La cantidad de inter\u00e9s mostrado en Flutter ha alcanzado un m\u00e1ximo hist\u00f3rico, lo que es tanto bienvenido como necesario desde hace tiempo. Android, iOS, macOS, web, Windows y Linux son todos compatibles con el kit de desarrollo de software (SDK) de c\u00f3digo abierto de Google. Todos estos est\u00e1n soportados por una \u00fanica base de c\u00f3digo […]<\/p>\n","protected":false},"author":23,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","om_disable_all_campaigns":false,"footnotes":""},"categories":[1159],"tags":[],"class_list":{"0":"post-19416","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-uncategorized-es"},"yoast_head":"\n\u00bfEs Importante la Prueba Unitaria?<\/h2>\n
\n
\u00bfQu\u00e9 podemos probar con las pruebas unitarias?<\/h2>\n
\n
\n
Unos puntos sobre el funcionamiento de Flutter<\/h3>\n
flutter test<\/code>. Flutter ahora puede leer, ejecutar y evaluar pruebas unitarias debido a las contribuciones de la biblioteca. Adem\u00e1s, la carpeta\u00a0test<\/code>\u00a0utilizada para almacenar pruebas tambi\u00e9n es creada autom\u00e1ticamente por Flutter. Por lo tanto, es de suma importancia no renombrar o reubicar la carpeta\u00a0test<\/code>, ya que hacerlo interferir\u00e1 con su funcionalidad y, como resultado, con nuestra capacidad para ejecutar pruebas. Adem\u00e1s, es vital agregar el sufijo\u00a0_test.dart<\/code>\u00a0a los nombres de nuestros archivos de prueba. Esto se debe a que Flutter usa este sufijo para identificar archivos de prueba.<\/p>\ntest<\/code>, repliquemos la estructura de carpetas de nuestro c\u00f3digo fuente y coloqu\u00e9mosla bajo\u00a0test<\/code>. Despu\u00e9s de eso, cada vez que escribamos una nueva prueba, la pondremos en la subcarpeta relevante, que son las siguientes: Las pruebas unitarias de las clases Modelo deben colocarse en una carpeta titulada\u00a0model<\/code>, as\u00ed como los calcetines limpios deben colocarse en el caj\u00f3n de calcetines de tu c\u00f3moda y las camisas dobladas deben colocarse en el caj\u00f3n de camisas.<\/p>\n\u00bfCu\u00e1les son algunas de las mejores pr\u00e1cticas para las pruebas unitarias?<\/h3>\n
\n
\n
Simulaci\u00f3n (Mocking)<\/h3>\n
MockTail es una abreviatura de “Sin Generaci\u00f3n de C\u00f3digo”.<\/h3>\n
Para tus mejores servicios de pruebas unitarias, y para consultar con expertos en pruebas unitarias, \u00a1cont\u00e1ctanos ahora!<\/h3>\n
Preguntas Frecuentes (FAQs)<\/h3>\n
test<\/code>\u00a0proporciona la infraestructura b\u00e1sica para desarrollar pruebas unitarias, y el paquete\u00a0flutter_test<\/code>\u00a0contiene utilidades complementarias para probar widgets.<\/p>\n