Mockito: pruebas de unidades

1. Te damos la bienvenida a este curso.: Hola chicos y bienvenidos a este curso sobre el marco de pruebas de unidades Java, Mockito. llamo alzas y soy ingeniero de software que ha estado usando este framework en mi flujo de trabajo de codificación desde hace bastante tiempo, cuando oí hablar de la posibilidad de crear un curso para explicar más sobre su uso y también beneficios. Estaba bastante ansioso por desarrollar uno. Esta clase se estructurará en 11 lecciones que pueden hacer ping pasos prácticos para que usted tome con el fin entender exactamente lo que se puede hacer con Mockito, primero evolucionaré mostrarle cómo configurar un local ambiente en tu máquina con Mockito en ella. Entonces echaremos un vistazo más de cerca a todas las formas en que estos dos nos facilitan las pruebas unitarias. Cosas como especia, emparejadores de argumentos, las funciones en orden y verificación, especificando valores de retorno para métodos y así sucesivamente. Si te interesa mejorarte camino alrededor de las pruebas unitarias en Java, este curso es para ti. No hay otros requisitos previos después una computadora con conexión a Internet. En cuanto al proyecto de esta clase, será extremadamente práctico y te implicará seguir los pasos presentados durante este curso. Para que puedas comenzar en tu viaje de escribir pruebas unitarias para el código que estás desarrollando usando Java. Pensamos, dijimos, creo que ya te vemos en la primera lección. 2. Instalación del JDK: Chicos, bienvenidos de nuevo a este tutorial. En este tutorial, vamos a empezar a aprender por supuesto, preparando nuestro entorno en nuestra máquina local. Entonces, en primer lugar, por supuesto, al ser el framework que está usando código Java, necesitamos asegurarnos de que tengamos el JDK instalado en nuestra máquina local. Entonces el PIB proviene del SDK de Java. Sdk proviene del kit de desarrollo de software. Para este tutorial. Vamos a utilizar la versión de un punto punto 01 para Java 16. En primer lugar, debes asegurarte tener estos JDK instalados en tu computadora. Ahora, tengo aquí una máquina Windows. ¿ Cómo verificarías si tienes este JDK ya instalado en tu computadora o no lo tienes, solo necesitas ejecutar tu CMD. Entonces tu símbolo del sistema con administración, y luego escribe en cada versión de dash java. Como se puede ver, no lo tengo instalado. Y lo que trae en mi pantalla es que Java no se reconoce como un comando interno o externo, no está instalado. De esta manera puedes confirmar que no lo tienes instalado. Si hubiera sido instalado, el mensaje sería algo así como versión Java y luego te dirá la versión, luego algunos otros mensajes agrícolas. Pero ahora que sabemos que no lo tenemos instalado, vamos a ir en la tienda de imágenes. Si ya lo tienes instalado, puedes saltar al siguiente paso que va a ser en unos minutos. Pero por ahora, cómo lo instalarías sería ir al enlace que proporcioné en esta pantalla aquí mismo, y eso es oracle.com, tecnologías Java. Java SE descarga el HTML. Esto se puede ver tenemos aquí el trabajo de descargas Java SE, veo 16. Y podemos hacer click debajo del Oracle JDK en JDK descarga. Ahora nos redirigirá al Java Development Kit 60. Por lo que ves Java SDK y luego desplazándote hacia abajo, puedes elegir la versión para tu sistema operativo, en mi caso, es un Windows 64 beats, por lo que es la versión aquí mismo. Seleccionaré directamente los archivos ejecutables para que podamos seguir y revisar el acuerdo, luego haga clic en Descargar. Se puede ver que el ejecutable en realidad se está descargando en este momento. En tan solo unos segundos, se hará para que podamos hacer clic en el clavo. Y como lo pueden ver iniciando esta instalación, bienvenidos a la instalación. Podemos hacer click en Siguiente. Ahora, el baño por defecto donde lo instalaría. Y te sugiero que lo dejes SEC es Archivos de Programa C, Java, dish, y luego la versión JDK de la misma. El motivo por el que les digo que lo dejes de esta manera es porque posteriormente estaremos estableciendo algunas variables del entorno. El spec. Y si lo cambias, vas a necesitar recordar que Beth ha cambiado los dos y tenerlo puede estar basado en el documento del Bloc de notas. Pero por ahora solo podemos seguir y hacer clic en Siguiente. Y como se puede ver, básicamente comenzará a instalar sea GDK, que estaba completamente instalado. Podemos cerrarla. Y así así, se hace el primer paso de este tutorial. El segundo paso, como dije, necesitamos establecer una variable de entorno, más específicamente la variable de entorno doméstico Java. Y tenemos que apuntarlo al baño donde detenemos estos JDK. Entonces para hacer eso, debes ir al botón Buscar, luego escribir las variables de entorno del sistema. Haga clic en Entrar. Entonces aquí sobre variables de entorno. Entonces podemos hacer click en Nuevo. Entonces tenemos el nombre de la variable, que va a ser Java bajo casa, y luego el directorio de navegación. Y entonces el directorio va a BSA dijo Local Disk C Program Files, y luego por supuesto Java, y luego este JDK por la deuda, nos consiguió. Entonces esto va a estar bien. Y como se puede ver aquí, ahora se agrega la variable de sistema doméstico Java y el valor de la misma es la Beth real. Ahora podemos además, aparte de agregar la variable de sistema de Java home con el valor de la ruta aquí en bat, necesitamos editar esto y también agregar nuevo. Y luego necesitamos gráficos para la deuda de la carpeta bin con edit aquí. Y luego como se puede ver, el Java JDK y estas carpeta de estar justo aquí después de que llegué, iniciaron mi computadora. Porque si no lo reinicias, no podrás ver que el Java instalado cuando lo reinicies e ingresas java dash version, puedes ver que en realidad te dice alguna información sobre los atributos y específicamente el hecho de que el JDK instaló con éxito en su computadora. Una vez más, agregué a las variables del sistema en Java subrayado home establecido a la ruta donde se instaló el GDK y lo agregué a la parte posterior. Entonces las variables de usuario para tu usuario, luego haces clic en él, haz clic en Editar, y luego en el nuevo navegador, y luego en la carpeta bin de la respiración de instalación JDK. Si lo haces después de instalar el JDK que obtienes desde este enlace, vas a instalar correctamente el JDK en tu computadora y completar los dos primeros pasos. Por ahora. Esto fue sobre el Enter. Les agradezco muchísimo chicos por quedarse conmigo hasta el final de esta conferencia. 3. Instalación de IntelliJ IDEA: Hola chicos y bienvenidos de nuevo al tutorial. Para este tutorial, necesitamos obviamente tener un IDE en el que podamos saltar código. Y para eso vamos a utilizar la idea IntelliJ IDE, que mi opinión es el mejor IDE para java por ahí. Pero solo podemos empezar a crecer para inteligentes y luego hacer clic en la página web Download on JetBrains. Esto te redirigirá a la descarga de la idea de Intel G. Ahora por supuesto que vamos a utilizar la versión comunitaria. No lo último es no escribir código para ella empresa. Sólo vamos a utilizar estos desde la comodidad de nuestros propios hogares. Pero si quieres hacer eso por todos los medios, si tienes una empresa o algo así, puedes ir por lo último. Es sólo que para este tutorial, vamos a ir con las ventanas dot EXE. Y como se puede ver, la descarga básicamente comenzó. Voy a volver con ustedes una vez que termine. De acuerdo, así que estoy de vuelta que Intel ha sido descargado cuentas y ahora cuando hacemos clic en estos archivo ejecutable, vamos a ser recibidos por unos procesos de instalación. Se puede ver el fin de semana de configuración simplemente seguir en la instalación. Se come nuestra carpeta de destino predeterminada en la unidad C. Ahora, la longitud de 64 bits es lo que vas a necesitar para seleccionar aquí. Entonces vamos a asociar con ello los archivos Java. Entonces podemos actualizar el menú contextual, editar la Carpeta Abierta es proyecto. Los lanzadores directorios a la cama. No creo que eso sea necesario es que vamos a abrir las cosas desde la aplicación real para que podamos seguir y hacer clic en Siguiente y después instalarlo. Después de que se haya instalado, te van a saludar con estas ventanas finales. Y se puede optar por ejecutar Intel J después de estos realmente terminados de instalar y podemos hacer click en deuda. Confirmamos que hemos leído y pulsamos en Continuar. Se puede ver que el Intel G ID se va a abrir en este momento. Y nos pedirá abrir un proyecto o crear uno nuevo. Y luego por supuesto, algunos plug-ins en la ventana de personalización con respecto a Temas de Color y cosas así. Entonces esto fue por ello con la instalación de GID para el trabajo que vamos a utilizar en este tutorial. Es un WordPress bastante simple y recto es, pero pensé que debería hacer el tutorial sobre estos solo para asegurarme de que ustedes estén al tanto de la forma en que se van a poner en marcha. Ojalá hayas sacado algo de este tutorial, y realmente espero verte en el siguiente. Muchas gracias por seguir conmigo hasta el final de esta conferencia. 4. ¿Qué es la maqueta?: Hola chicos y bienvenidos de nuevo a este tutorial de Mockito donde entendemos cómo podemos mejor contra nuestros métodos Java usando estos framework de pruebas. En esta conferencia, vamos a echar un vistazo a algunas nociones teóricas sobre burlas. Justo antes de sumergirnos profundamente en el marco de pruebas de Mockito y entendemos cómo podemos escribir código para probar nuestros métodos. Vamos a cubrir algunas cosas básicas como lo que se burla, lo que se debe marcar, diferentes tipos de marcas y este tipo de cosas. Simplemente para poder tener un buen conocimiento de ellos antes de aplicarlo. Entendemos el proceso al que vamos a ir donde escribir el código real en nuestros identificadores. Ahora en términos simples, el proceso de marcado se refiere a proporcionar control, instancia o implementación, o incluso dependencia de la que depende el código bajo prueba. Con el fin de probar cada lógica de núcleo. En el caso de nuestra primera aplicación Mockito, la silla va a mirar en la próxima conferencia de la sección antes de entrar en características más detalladas de Mockito, te voy a presentar un básico aplicación utilizando Mockito y en aplicación de deuda. El método que será referenciado en una función que queremos probar será burlado y se hará por pedirle devuelva un valor específico que deseemos. Entonces esta es la práctica de marcar. Estas marcas vienen a rescatar en las situaciones donde no importa si eres dependencia está arriba y entrenando o no, siempre estás garantizado para ejecutar tu lógica empresarial con una respuesta programada para la dependencia que se llama desde el código bajo prueba. Si alguna vez escuchó la tercera prueba doble se refiere esencialmente a un objeto que es reemplazado por una instancia equivalente de árbol u objeto o dependencia. Existen dos ventajas principales en cuanto a por qué los procesos de burla son útiles al probar nuestro código. Puedes pensar en estos como los pilares base en los que basamos el uso de nuestras pruebas unitarias. La primera ventaja es la eficiencia que trae consigo el proceso de fumar. Porque con burla, estamos seguros de que solo hay nuestro código que se ejecuta. Al ser probado. Todas las demás dependencias tendrán valores codificados duros, burlados dados por nosotros y ese código no se ejecutará en realidad. Ahora, la otra razón es respecto al control exacto que tenemos en todos los demás componentes que nuestra función de prueba IF necesita. Esto puede crear una separación que es muy beneficiosa. Ayudándonos de esta manera a ver rápidamente si la función que queremos probar se está comportando AES-128 o no como las partes que se utilizan en el proceso que en realidad no son parte de la función que queremos prueba. Tendremos valores establecidos que serán marcados por nosotros. Ya sabremos cuál es el regreso y cómo se comportan. Y sólo limitamos nuestras pruebas. La función que en realidad queríamos probar. Existen diferentes tipos de dobles de prueba o marcas. Y vamos a correr por cada uno de ellos solo para que tengas una mejor comprensión de su clasificación. Y en una conferencia futura, si ves uno de estos nombres, vas a estar familiarizado con él y rápidamente entender y tener un punto de referencia en cuanto a qué exactamente ese tipo de este doble E. En primer lugar, tenemos las falsificaciones. Las falsificaciones están trabajando implementación que es bastante similar a una dependencia real, excepto el hecho de que esté situada en la máquina local donde el código bajo prueba realmente se está quedando. Aquí, el ejemplo que más se usa y el escenario que somos falsificaciones son los más útiles. Al tratar con la persistencia de Theta. Al tratar con bases de datos. Y en lugar de instalar una base de datos de producción real, test utiliza una colección simple o una en memoria para almacenar datos. Y por qué eso es muy útil es porque es posible que no quieras, para cada prueba que hagas para poblar realmente algunas filas en la base de datos de producción real. O incluso tienes una base de datos de pruebas. A lo mejor no quieras poblarlo porque puede surgir algunos problemas cuando hacemos eso. El primero sería que Daniel tenga que eliminarlo. segunda sería el tiempo y la eficiencia que se desperdicia en estas dos operaciones. Incluso decir que base de datos no es ni siquiera profundidad que se quiere probar. Queremos probar un método que está llamando a la base de datos real. Querías ver cómo se comporta la función y no si la llamada a la base de datos realmente está funcionando, eso debería ser en otra clase. Si tienes una buena separación en tu proyecto. Y esa clase debe estar en el proyecto de repositorios, donde el personal respecto a la base de datos todavía está retocando. Qué falsificaciones se utilizan la mayoría de las veces. Son muy importantes desde esto una perspectiva. A continuación tenemos los talones. Y estos productos son solo respuestas preconfiguradas cuando se llama a una dependencia desde el sistema que estas 100 prueban. Ahora, aparte de paradas, también tenemos Spice. Estas son diferentes a las paradas, falsificaciones y también marcas porque la función real o dependencia realmente se llama. En especia. Tiene algún mecanismo de observación que se adjunta a esta convocatoria para prueba Delta B y publique la llamada a este mecanismo de observación. Se puede verificar si el carbón fue realmente activado o no junto con los parámetros. Y por último, tenemos el tipo de doble prueba más importante que vamos a concentrar la mayoría de este curso. Esas son las burlas. Las marcas son instancias especiales de objetos y las respuestas de los sujetos pueden ser especificadas por el probador. Eso es lo que los hace únicos. El hecho de que el intestino Mach llamado se puede verificar aseveración SAML en la prueba. Y este va a ser el ángulo en el que brillaremos Mockito, como verán en el proyecto de vista previa del que estoy hablando. Y nos meteremos en eso en tan solo un momento en la próxima conferencia. Facilita la creación de objetos simulados a la perfección. La forma en que hace esto es mediante el uso de la característica de reflexión en Java para crear objetos simulados para una interfaz dada. Entonces tienes una interfaz y básicamente crea un objeto instanciado como concreto. Pero ese concreto no existe realmente. Simplemente lo marcas hasta que lo inventas y lo haces devolver algunos valores que piensas en línea que te interesan para los valores de deuda aparezcan en la función que realmente quieres probar . Y además, para ver de nuevo cómo se comporta la función cuando tiene parámetros de entrada controlados dados I, ya sea como parámetros o como los resultados de las funciones que se llaman Imagen larga. Ahora, solo unas palabras sobre por qué Moche W tan popular y debes elegir estudiar, es que este framework te permite crear y configurar estos objetos simulados de los que hablamos. Eso sería bastante obvio por el título de este marco también. Pero el uso de Mockito simplifica en gran medida el desarrollo de pruebas que haces para cualquiera de las clases con dependencias externas o métodos simples dentro de estas clases. Si usted, el marco estadístico de prueba, puede, como ya he dicho, burlarse de las dependencias externas y también insertar las marcas en el código bajo prueba. Dosis que quieras dar estos valores específicos a funciones dentro de la función que quieres probar para ver cómo se comporta. Puedes, por supuesto ejecutar el código bajo prueba con mono DO y también validado el código se ejecuta correctamente en este entorno controlado que configuraste con el proceso de marcado. Esto se trataba de comer por las nociones teóricas burlantes que disparas, tener en su lugar justo antes de empezar la burla real en código y ver cómo funciona eso. De ahí, encendido. En la siguiente conferencia, vamos a ver una rápida mirada al primer proyecto de Mockito que habré configurado usando el solutor de dependencia de grava. Y si eso suena interesante, espero veros chicos en la próxima conferencia. Y muchas gracias por quedarme hasta el final de éste. 5. Mira un proyecto de Mockito: Hola chicos y bienvenidos de nuevo a este tutorial de Mockito donde entendemos cómo podemos probar mejor nuestros métodos chatbot usando este marco de pruebas unitarias. Para esta conferencia, vamos a echar un vistazo rápido sobre cómo podemos configurar nuestro proyecto en Nueva Delhi para que podamos escribir pruebas unitarias que están utilizando principalmente el framework Mockito. Una vez que abras IntelliJ, puedes hacer click en Nuevo Proyecto para que obviamente lo suficientemente griego, un nuevo proyecto. Entonces en esta ventana que ves en la pantalla momento necesitas seleccionar Gretel. Entonces necesitas tener Java marcado y el SDK de Java que has descargado en tu máquina local. Ya tuve una conferencia ahora puedes hacer eso. Pero si ya lo tenías instalado, puedes, por supuesto, añadir JDK. Así parpadea el camino que tienes en tu máquina local o puedes descargar directamente el TFEU no siguió ese paso de descargar tu GDK directamente desde el inteligente, pero lo conseguimos. Por lo que podemos hacer click en Siguiente. Aquí están los nombres de nuestro proyecto. Voy a nombrar mi proyecto o tutorial. Y la ubicación va a ser la predeterminada que se encuentra en la carpeta de proyectos Idea. Entonces el ID del artefacto va a vencer tutorial, el ID del grupo o los ejemplos de puntos ORT. Eso es bastante sencillo. Y al hacer click en Finalizar, ir a seleccionar la nueva ventana es que ya he tenido una ventana abierta con otro proyecto. Ahora se puede ver que tenemos proyecto básico abierto y está más o menos listo para escribir código en. Y se puede ver que cuando se abra, Gretel va a hacer que la iniciación se construya sobre ella. Solo para ver que todo está bien y tenerlo todo listo para funcionar. Se puede ver que la construcción fue exitosa. Y aquí en la parte derecha tenemos también un gran grifo del dedo del pie sin la tarea de construir, ensamblar, construir, y todas esas cosas buenas. Y puedes correr cada uno de estos para que digas que todo está bien, pero debería ser todo debe estar en orden en tu entorno si sigues los pasos que acabo de describir en conferencias de clase. Entonces lo primero que vas a tener que hacer para poner a Mockito en funcionamiento, es ir a este expediente de factura a ese Gretel justo aquí en la ventana del proyecto abriendo arriba y en la sección de dependencias en la línea 12, vas a necesitar ingresar estas dos líneas. Por lo que prueba la implementación de nuestro jeep. Ese Mockito, Mockito en la línea 377 y Mockito, necesitas a Júpiter 377. Una vez que ingreses estos dos valores, puedes ver que tienes este elefante. También tiene un signo de sesiones síncronas en la parte inferior derecha del mismo. Y si pasas el cursor sobre él, puedes ver que los medios que puedes permitir a los cambios graduales. Y básicamente detecta que la estructura del proyecto ha cambiado. Y para que estos cambios sean asimilados al sistema y se construyan en base a él y resuelvan todas las referencias, necesario cargar estos cambios graduales en. Una vez que haga clic en esto, se puede conseguir otra construcción se hizo. Y una vez hecho esto, básicamente puedes seguir y escribir tu código. El código se va a colocar en estas dos carpetas. Tienes la carpeta principal con la subcarpeta Java donde vas a colocar el lugar de trabajo, estas interfaces y así sucesivamente. Entonces básicamente ese es el código que se va a probar. El código de liberación. Entonces para nombrarlo en la carpeta de prueba, más específicamente de nuevo, en el trabajo una subcarpeta, vas a hacer clases de prueba. Las clases van a utilizar Mockito para probar los métodos de las clases que están disponibles y escritas por ti que quieres haber probado en la carpeta Java de la carpeta principal principal. Y por supuesto, solo puedes seguir después de esta configuración básica para madurar tu prueba unitaria de Mockito. Por supuesto que hay que importar Mockito, pero eso es sólo una línea de código. Más específicamente es importar ORT estática que Mockito punto Mockito con una letra mayúscula M y luego dot estrella para que recupere toda una biblioteca. Y luego después de eso puedes usar todas las cosas buenas como métodos de Mach cuando y así sucesivamente. Nos vamos por supuesto entrar en las próximas conferencias. Pero esto estaba por encima de él. Ahora si no ves que tu construcción de solución sencilla Gradle como en mi caso, se construyó automáticamente. Lo que hay que hacer es que tienes que hacer clic en esta cuadrícula azul y luego hacer clic derecho sobre ella y luego ejecutar tutorial. Y esta voluntad por defecto, ejecutar se construyen sobre todo el proyecto. Por supuesto, lo ejecutará con todas las dependencias a las que ingreses aquí mismo. Este era un entorno básico que necesitas tener la configuración en tu máquina local antes de ir más allá, este tutorial, si quieres hacer, en realidad tienes algunos siguientes buena experiencia. Entonces si quieres replicar lo que hago o lo hago a tu manera o formas similares, porque comienza con las dependencias y esta es la forma en que necesitas configurar tu proyecto Intel J. Pero esto fue por ello para esta conferencia. Espero verte en los próximos donde vamos a tomar unas palabras clave, nociones y cosas que el marco Mockito y hacer más en detalle, entenderlo y darnos una profunda inmersión en él. Eso suena interesante. Espero verlos ahí. Y una vez más, muchas gracias por quedarse conmigo hasta el final de esta conferencia. 6. Preparar tu primer proyecto de Mockito: Hola chicos, y bienvenidos de nuevo a este tutorial de Mockito, Java framework, donde entendemos mejor cómo podemos probar unitariamente nuestros métodos Java usando este marco de pruebas. Para, para esta conferencia, vamos a echar un vistazo a primera aplicación que tenemos, algunos de los conceptos en los que vamos a profundizar más adelante en este tutorial. Solo para que hagas la imagen de cómo se vería un proyecto en cada totalidad. Y también ¿cómo crearías el partiendo desde 0? Para empezar, vamos por supuesto, dirígete a nuestra EII elegida para Java. Eso es IntelliJ J, como viste en las últimas conferencias. En vas a crear un nuevo proyecto por supuesto. Y ya sea puedes ir a archivar nuevo proyecto o si no tienes ya un proyecto abierto, entonces no abrirá nada más que ventana inicial donde te rediriges para abrir un proyecto o un nuevo proyecto. Puedes configurar un nuevo proyecto y lo que quieres seleccionar Next es gradual. En lugar de simple Java. El motivo de eso es que hace que nuestro trabajo sea mucho más fácil a la hora de vincular el marco Mockito en nuestro proyecto. Entonces, en lugar de simplemente seguir y descargar los archivos GIA IR de repositorios Maven, el archivo JAR de la cresta del jamón, el Mockito, y también vincular las variables del sistema DOS a la parte posterior. Qué va a hacer esto. Calificador enlazará automáticamente a Mockito muy fácilmente ya que te mostraré en un segundo a nuestro proyecto. Por lo que usaremos grid off para este tutorial. si no lo sabes, te pasaré por una descripción rápida de qué crédito. Para que se te ocurra es sólo una herramienta para la automatización. Entonces, lo que hace, es automatizar la creación de aplicaciones, haciéndola mucho más fácil y más rápido. Estas son automatización incluye el enlace en empaque y compilar de diferentes partes de tu código. Pero por ahora, solo puedes elegir Gretel aquí en la densidad del proyecto j, necesitas. Por supuesto, elige JDK que instalaste. En tu máquina local. Instalamos nuestra deuda 16 JDK es detectada automáticamente por inteligente porque la dejamos en su propio camino predeterminado. Pero si eliges ese camino de una manera diferente o tienes instalada una versión diferente de JDK, debería ser automáticamente, como dije, ser elegido aquí. Pero si no lo hace, puedes descargar JDK si no lo tienes y se lo descargaría automáticamente. No tienes que pasar por todo ese proceso desde la conferencia anterior. O puedes agregar tu JDK si ya lo tienes instalado, pero no se detecta. Puedes elegir una ruta de donde instalas ese archivo bin. Pero por ahora, también puedes escoger Java y luego golpear a siguiente el nombre del proyecto y la ubicación. También el artefacto coordina como el ID del artefacto depende enteramente de ti. Por lo que esto no será de hecho nuestro proyecto de ninguna manera. Entonces al hacer clic en Finalizar, se abrirá un proyecto para usted forma predeterminada comenzando desde el ancho inferior no incluido. Por supuesto, vamos a hacer eso en una conferencia futura y te voy a correr a través exactamente de cómo se construyen las dependencias y qué debes hacer para importar Mockito y todo eso bueno. Pero esta conferencia es sólo el fin de mostrarte un proyecto rápido que he creado aquí mismo con algunas clases que en realidad están trabajando junto con el marco Mockito. Para probar un método específico de una clase específica, vamos a echar un vistazo solo para que te hagas una mejor idea de cómo funcionan las cosas en este marco de pruebas único. Se puede ver aquí tengo industrial see archivo, el archivo principal. Aquí tengo un Java. Un archivo, por supuesto, junto con el archivo principal, tenemos el testfile donde intuitivamente, vamos a escribir nuestros métodos de prueba. En el Java. Sólo vamos a declarar nuestras clases. Tipos de métodos que pueden ser queremos hacerse la prueba. Para empezar, tenemos aquí el vidrio del coche. Esta clase tiene tres campos, ID de coche, eso es una cadena, nombre, eso es una cadena y cantidad que es una cadena. Y nos imaginamos estos ejercicios como algún tipo de autoridad que está vendiendo autos se venden bien, lo llamé el concesionario. Y también contamos con un servicio de autos que facilita estos traslados. Ahora otra observación aquí es que cuando escuchas que la clase tiene servicio en su nombre, automáticamente debe estar pensando en esa clase está haciendo algunos métodos para sus otras clases. Hemos sido servicio de Estados Unidos en ella. Y si escuchas repositorio que algo que ver con persistir buenos datos, almacenarlos en una base de datos y así sucesivamente. Eso fue sólo un paréntesis rápido. Así que ahora avanzando, el auto de clase, por supuesto tiene un constructor con los tres parámetros que aún inicializaron aquí. Y luego conseguimos algunos setters y getters que son públicos. Y a través de esto, vamos a establecer o conseguir nuestros campos privados logren de esta manera. Encapsulación hecha, buenas prácticas. Esta es la lista, nada realmente fuera de lo común aquí. Apenas algunos campos que aún se establecen y obtienen la pared celular. Realmente no podemos probar nada aquí, pero vamos a ver que solo estamos probando o clase que fácilmente lo hacen. Bueno, estar más allá por aquí ahora, también tenemos los concesionarios de automóviles. Entonces este es el método que vamos a probar la celda de vidrio. En primer lugar, importamos Java util bestia ya que vamos a hacer uso de la lista aquí mismo en la línea 15. Pero el concesionario de autos de clase tiene que filtrar. Necesitas uno que sea servicio de autos, que es una interfaz y carta de vinos de autos porque el concesionario tendría al menos de autos, claro. Ahora el servicio de autos consigue getter y también un setter. Y luego la lista de autos también consiguen una en el getter. Por último, tenemos aquí otro método que se va a probar usando el caso framework. Verás en tan solo un momento, lo que hace es que declara una variable de tipo doble llamada valor de mercado, y la incrementa con 0. Ahora, vamos a iterar a los autos menos que es miembro de esta clase. Vamos a incrementar el precio get de un auto. Por lo que los servicios de automóviles pueden ver que es sólo una interfaz que tiene estas firma de obtener precio aquí. Y este es el método que nos vamos a burlar de usar Mockito para devolver algo que queríamos. Eso es lo que significa Mark. Y aparte de eso, vamos a multiplicar el precio que vamos a marcar el valor que vamos a dar. El método de cantidad que por supuesto está en la clase de auto. La cantidad que devuelve cuántos autos hay. Por último, después de iterar a través cada auto e incrementarlo con este valor de multiplicación, vamos a devolver este valor. Entonces como dije, el servicio de autos tiene esta firma, método que en realidad no se implementa. Y ahora vamos a pasar a la clase de prueba. Como se puede ver bajo prueba y Java, esta manera grid, no sabemos que este es el método de prueba. Aquí está la magia sucediendo, por así decirlo, y Mockito está involucrado. Esta es la clase de pruebas de tarjetas que sólo vamos a importar algunos utils que vamos a utilizar. Entonces con esto, se puede ver que estamos importando el Mockito. Como dije en una futura conferencia, vamos a ver exactamente cómo podemos importar estos Mockito usando Gretel. Estamos empezando a en la clase de probador de tarjetas aquí. Por lo que tenemos un concesionario de autos, el servicio de autos. El servicio es una interfaz. Aquí tenemos el método principal que es el punto de entrada donde vamos a ejecutar estos, este bastante sencillo. Estamos declarando probador de tarjetas, que es esta clase. Entonces lo vamos a instanciar y luego lo vas a llamar configuración para ello. Entonces la configuración es este método justo aquí que crea una instancia del concesionario y el servicio de automóviles. Se puede ver para el servicio de autos eso es sólo una interfaces que he dicho en realidad no implementado. Vamos a utilizar el método de simulacro de Mockito. Y te vamos a dar el servicio de autos y vidrio. Entonces vamos a simplemente marcar la clase ya que será clase concreta en no sólo una interfaz para el concesionario. También vamos a configurar el servicio de autos a estos servicio de autos marcados, como se puede ver aquí siguiente en método principal después de que configuramos estas pruebas, su objeto de probador de tarjeta tipo, estamos yendo a codificar este valor de mercado de prueba. Y dependiendo del booleano y regresa, vamos a comer ese enmarcado mejor si la prueba pasa o falla. Si falla. Profundizando en ese valor de mercado de prueba, un método. Aquí sólo vamos a declarar una lista de autos. Entonces voy a instanciar en realidad dos objetos de tipo auto. El primero fue Lamborghini y el segundo siendo un Audi. Va a usar el constructor con todos los valores reales. Les vamos a dar alguna identificación de stock, algunos nombres y las cantidades que tenemos para aprender trabajando bien. Y tres son estos, ambos de estos autos, que en realidad son listas de autos porque estos van a empezar a usar estos tres o estos se van a sumar a nuestra lista, claro, que se llama los autos como se puede ver en línea allí a 1637. Después el 40, vamos a llamar al método en el objeto concesionario. Eso es un concesionario de autos. Lo que hicieron estos set cards método fue, si recuerdas ajustar la atribución de la lista que le damos como parámetro a la lista de campo al concesionario de autos. Además, después de hacer eso, aquí es donde demo.com escena y por supuesto vamos a tener una conferencia posterior donde explicaré exactamente qué hace este método. Pero por ahora, solo para que puedas obtener el panorama más grande, lo que este método de cuando recibe básicamente una Llamada. Dice cuando el método de precio de la brecha del servicio de Cristo sería llamado con un parámetro de Lamborghini. Entonces deberías leer 250 mil, que sería el precio de Lamborghini que estimé. Y luego de nuevo, cuando obtengan precio método de servicio de auto sería llamado usando el auto, entonces deberías devolver 50 mil. Nuevamente, marca estas llamadas. Entonces el código en realidad no tiene que pasar por todos obtener clase de precio porque solo vas a querer probar el método de valor de mercado. Y eso es lo que hace. Se marca el vaso del método de conseguir Bryce. Y después de que veamos estos, se puede ver que vamos a llamar a la función get market value desde el vidrio concesionario, que fue éste. Y como pueden ver aquí, estamos marcando el método NET-price porque eso no es lo que queremos probar. Solo queremos que esto consiga el método de valor de mercado. Y como dije, cuando esto sería llamado, iteraría a los autos y en primer lugar, lo entregará al número guineas. Y cuando el servicio de autos conseguir precio de Lamborghini sería llamado, el Mockito te dice que regreses a 50 mil y ni siquiera te molestes en llamar al real get price, que por supuesto ni siquiera es implementado porque se trata de una interfaz y lo estamos marcando. Entonces todo el ADI de la misma manera y bestia nos permite probar el método get market value en condiciones muy controladas y también muy eficientemente ya que obtienen método de precio no va al frío et al. Vamos a, como dije, llamarlo desde el concesionario. Después de eso, vamos a girar el valor de mercado es igual a 650 mil, que sería el valor correcto dado que 250 mil veces dos es 525,000 mil veces 350 mil. Suman esos dos y obtendrías 650 mil. Por supuesto que ahora, se va a imprimir ya sea pass o fallar, dependiendo de estos true o no, el valor que este valor de mercado de prueba devuelve. Entonces si hacemos clic derecho en la clase probador de autos, decimos dominio Ron Cortez. Se puede ver que en este momento es realmente construir todo el proyecto arriba y el interés. Segundo, se puede ver que es un mejor. Ahora veamos si funciona. Si aquí tendríamos 65 mil, que no es el valor correcto, se debe conseguir un fail aquí. Entonces veamos si eso sucede. Ocurre. Ahora bien, esto fue sobre escritura para la primera introducción sobre Mockito. Al ver un proyecto más grande en la ciudad, Mockito se acostumbraría a un proyecto ya establecido. Pero a partir de la siguiente conferencia, vamos a presentar poco a poco desde el principio cómo puedes crear tu primer proyecto. Presentan también palabras clave y características particulares del marco Mockito y cómo se utilizan, qué hacen, etcétera. Entonces si eso les suena interesante, espero veros ahí chicos. Y muchas gracias por quedarse conmigo hasta el final de este tutorial. 7. Especifica los valores de retorno: Hola chicos y bienvenidos de nuevo a este tutorial de Mockito donde entendemos mejor cómo podemos probar nuestros métodos en Java usando estos framework de pruebas unitarias. En esta conferencia, vamos a echar un vistazo a cómo Mockito puede especificar valores de retorno en diferentes escenarios para algunas funciones que se llaman en diferentes tipos de situaciones. Con Mockito, puede agregar funcionalidad para marcar un objeto utilizando diferentes métodos. Se puede ver que lo hicimos aquí en nuestro escritorio en la línea 23. Marcamos toda la clase de servicio de autos que estaba en una interfaz y encabezamos ninguna implementación real. Pero aparte de ese riñón de Mockito, también puede marcar el comportamiento de una función que se llama con ciertos parámetros. Y al marcar la deuda, puede especificar el valor de retorno exacto que debe tener esa función cuando se llama con ese parámetro específico. Por ejemplo, en línea 43. Como se puede ver, el Mockito instruyó la función de obtener precio del servicio de automóviles, que en realidad no tuvo implementación en la interfaz. Para devolver los 250 mil fallan a la hora de hacer frío, podríamos el argumento de Lamborghini. Y como se puede ver, la sintaxis apilada para eso es la palabra clave wing. Entonces la función que se va a llamar con un parámetro específico. Por lo que la deuda es la situación en la que se quiere que se añada este comportamiento. Y luego la palabra clave den return, y luego el valor, la función que se está llamando con ese parámetro específico debería tener en situación exacta de deuda. En este punto de tiempo. Mock ya grabó el comportamiento y se está trabajando objeto simulacro, tipo de servicio de coche de interfaz. El objeto de servicio de automóviles ya es un objeto simulacro de trabajo. Nuevamente, ya dije esto, este código aquí mismo es muy útil porque este código se ejecutará en el concesionario, obtendrá valor de mercado. Vamos a probar y queremos que esas dos llamadas tengan nuestros valores exactos dados, valores marcados, solo para que nos aseguremos de que esta función vaya bien o no con respecto a estas función de get precio. Entonces si la función de get price funciona o no, método definido dos veces, porque especificamos los valores que debe devolver. Y queremos concentrarnos en pruebas unitarias para obtener método de valor de mercado. Este es el método básico de cuándo y luego regresar, que es dijo ELLA, el marco Mockito especificando los valores de retorno. Como podrían pensar algunos otros programadores. Esto está agregando el comportamiento. En ciertos tipos de situaciones. Eso es algo bastante útil cuando se quiere crear esa separación de la que hablamos de la clase que se quiere probar en la dependencia bajo y clases que se llaman dentro de ella. Entonces esto fue por encima de escritura para esta conferencia. Y en la siguiente vamos a empezar a mirar la palabra clave verificada, que es una palabra clave muy importante, demo dope, framework de pruebas unitarias. Y vamos a ver exactamente lo que hace y todos los diversos escenarios que son muchos de ellos que verifican palabra clave se pueden utilizar. Eso suena interesante. Espero veros ahí chicos y muchas gracias por quedarse conmigo hasta el final de esta conferencia. 8. Verifica el comportamiento de los métodos: Hola chicos y bienvenidos de vuelta al ahumado le dijo a Turiel. Dondequiera que entendamos cómo podemos mejor prueba unitaria nuestros métodos escritos en Java usando este framework. En esta conferencia, vamos a hablar del método de verificación que nos proporciona Mockito. También cómo podemos usarlo y por qué útil para nosotros al intentar unitar este uno o incluso más métodos que escribimos en la R. Tal vez en producción o tal vez queremos desplegarlos en algún momento en el futuro. Así que al empezar aquí, creé un proyecto completamente nuevo en Intel J. Y la forma en que lo hice eso fue bastante parecido al otro que vimos en la conferencia anterior donde presenté el visión general de un proyecto para usted. Más específicamente, acabo de hacer clic en File New Project. Y luego cuando eso se abrió, elegí el sistema de resolución de dependencias Gradle, elegí Java, y luego el JDK de mi elección. Entonces en el siguiente acabo de elegir un título para ello, lo mismo para las coordenadas del artefacto y luego hago clic en Finalizar y luego creó mi proyecto para mí. Después de eso, acabo de ir a construir gradle e importé algunas cosas a algunas dependencias que vamos a necesitar para que estos proyectos funcionen. Ser más específico que la deuda. Usado JUnit y también los paquetes Mockito. El API JUnit Jupiter ya estaba aquí después de que incluirás estos. Como recuerdas, si cambias algún carácter de DC build gradle archivo, obtendrás el auto y con el botón de sincronizar en el que debes hacer click para que se importe en sincronizado con todas las dependencias más recientes, justo en el archivo de compilación Gradle. Después de que hice eso, la fuente se archiva con la media y se crearon carpetas de prueba después de que se construyera el proyecto. En la carpeta Java, tengo una clase y la interfaz. A la clase se le llama aplicación de facturación, y la interfaz se llama servicio de tienda de bonos. El servicio de casa de empeño tiene dos métodos que necesitas para vender y comprar. Uno, no se implementan en absoluto en la aplicación de facturación. Eso es en realidad una clínica, no una interfaz. Tengo estos campos privados. Ese es un tipo de servicio de tienda de fuentes, que era la interfaz. Y luego tengo el servicio de tienda de granero conjunto, que establece mi campo de servicio de tienda de bonos. Entonces tengo función celular que solo agrega dos números. El primero debe ser el beneficio total que ha tenido el puñetazo hasta este punto. Y el segundo debería ser en realidad el precio por el que vendemos nuestro objeto específico. Nuevamente, estos son más o menos sólo para un ejemplo en que no se implementan en una medida en la que serían intuitivos o nada por método también. Eso llama a la bicicleta desde el servicio punch up, que como viste, no se implementa, pero vamos a ver cómo funciona eso en tan solo un segundo. Ahora donde se pone interesante, porque hasta este punto fue bastante parecido al otro proyecto que miramos. Facilidad en la carpeta de prueba, donde tenemos automáticamente la carpeta java creada y yo creo estas dos funciones aquí. Estas son ambas clases. Uno se llama los probadores de aplicaciones de facturación. Por lo que cada aplicación de prueba para pantallas que ves en la pantalla aquí mismo no facturó la aplicación uno. Y luego tengo un test runner que tiene la función principal que necesitas, como veremos en un segundo, es el responsable de ejecutar realmente toda la clase de escritorio diferente es que tendríamos en esta carpeta, en mis limitaciones, sólo una. Pero en un proyecto de producción más grande, puede haber muchas gafas de prueba. Sé que es bastante útil para ejecutar dam en lugar de tener dominio en cada uno de ellos porque eso sería mucho más tiempo hacer clic mucho desde botones en cada uno de los proyectos. Además, a la prueba de solicitud de facturación aquí mismo. Como se puede ver, es bastante diferente a la que vimos en el último proyecto. Y la principal diferencia es que esta clase de probador se lee con el entrenador JUnit. Y como viste si recuerdas, importamos unidad de intercambio en mi caso es 4131, la versión. Y explicando un poco cuáles son estos puntos, un corredor JUnit es solo una clase que extiende la clase runner de JUnit, que es abstracta. Estos límites se utilizan para ejecutar las clases de prueba. Tienen cierta paciencia con el signo en que ayuda al proceso de construcción entender qué objeto es la marca, qué objeto es el objeto que debe inyectar el simulacro de él también, y también las funciones de prueba. Las pruebas JUnit se inician utilizando la clase core JUnit. Y esto se puede hacer desde ejecutarte desde la línea de comandos. Pero en nuestro caso, esto se va a hacer por defecto, por nuestro IVE cuando vamos a presionar el botón Ejecutar en la unidad de disco que tiene el método principal. Lo veremos en un segundo. Estos JUnit runner utiliza reflexión para encontrar el entrenador apropiado para las mejores gafas de prueba. Y por supuesto, primero va a buscar la anotación del ancho de rima en la clase de prueba, y no se encuentra ningún otro corredor. Se utilizará el corredor predeterminado. Se instanciará y la clase de prueba se pasará al corredor. En nuestro caso, las deudas, la clase probador de aplicaciones. El trabajo del corredor es instanciar y mejor vidrio de prueba. Entonces, ¿esa es la carrera o es bastante sencillo? Simplemente nos ayuda a ejecutar nuestra prueba en Intel J mediante el uso intuitivo y condiciones el fin de mostrar al ID qué componente es switch n ¿Cuál es el papel de cada actor en este proceso? Ahora, pasando al corredor de pruebas y volveremos a entrar en este mejor en su clase en tan solo un poco. En la clase test runner, se puede ver que tenemos la función principal y tenemos un resultado que se asigna al método JUnit run classes. Y eso se da como el parámetro d clase de prueba. Como dije, la unidad de cadena o va a ejecutar la clase de pruebas. Y por supuesto, estas anotaciones le van a ayudar a hacer eso. El resultado se asigna a las clases troncales JMU. El núcleo de dos minutos clasifica ese vidrio usando reflexión y luego pone el resultado en esta variable de resultado aquí mismo. Ahora vamos a iterar a través de estos fracasos de resultados. Por lo que estos resultados objeto tiene un método máximo llamado get fallas y devolverá todos los fallos si hubo alguno en nuestra prueba. Y se va a imprimirlos en la pantalla. Por supuesto, también va a imprimir si nuestro resultado fue exitoso o no en DC va a imprimir verdadero si todas las pruebas fueron exitosas o falsas si algunas de ellas estaban fallando, como se puede ver en la descripción en pantalla, momento, esta era más o menos la estructura de nuestro proyecto. Vemos en la pantalla. Solo quería mostrarte todos los elementos que hice en detalle. Simplemente así si quieres seguir junto con este proyecto o tal vez incluso escribirlo y luego modificar que estás en línea. Vas a poder hacer eso. Después de esta presentación. Voy a entrar más en profundidad en el concepto del que realmente vamos a hablar en esta conferencia. Y verifica método, la clase pública de pruebas de aplicación de facturación que escribí en la pantalla aquí, hace algunas cosas que son muy conocedoras dentro del Mockito marco en su basurero, muy bueno con este marco y por eso quería presentárselos. En primer lugar, declara objeto de aplicación de facturación. La anotación de Marcas de Inyectar prueba que este es el objeto donde se debe inyectar la marca. Y como puedes ver aquí, el servicio de casa de empeños es la marca porque es sólo una interfaz y debemos inyectarlo en este vaso. Ahora también declaramos dentro de estos testados sobre objeto de servicio de tienda, que anotamos. Eso es en realidad un simulacro como viste, iterando, Esa es una interfaz y debemos comercializar y comportamiento de mercado para devolver exactamente lo que queremos devolver y que en realidad lo tienen implementado. Recuerde, estamos haciendo estos con el fin de evitar sobrecarga en las pruebas de nuestras clases de producción. O bien al no querer recrear todos los flujos de base de datos en tan solo algún simulacro dado por nosotros valores y también para controlar mejor el flujo de partes a menudo funcionan que en realidad no están relacionadas con él. Y solo queríamos probar esa función por separado de cualquier otra clase. Y ahora la prueba en función, que es la prueba única real que escribimos en esta aplicación. Como se puede ver, esto se anota con el signo de prueba. Vamos a, en primer lugar, al comportamiento usando Mockito, que cuando se vaya a llamar al método de venta de servicio de la tienda de empeño con los parámetros de 1020, daño debe devolver 30. Estamos agregando este comportamiento es lo contrario esta línea de código aquí mismo no habría existido. El servicio de casa de empeño con el método celular con devolver nada ya que ese método no es componente, agregamos el comportamiento. Y entonces vamos a probar estos agregar funcionalidad y afirmar si el método de venta de servicio de tienda de empeño con los argumentos de 1020 realmente devolverá 30 S que instruimos hacer. Y vamos a hacer esto como se puede ver con el método assert, que pertenece a la clase JUnit, referencia JUnit es muy importante aquí. Y entonces este lugar tiene un método assert iguals, como se puede ver, que toma dos objetos y luego comienza si son iguales o no. Eso es bastante sencillo. Ahora, podemos verificar el comportamiento usando estos verificar la palabra clave y también método. Verificar comportamiento dice que debemos verificar el método de venta de servicio de tienda de empeño con los argumentos luego en 20. Lo que esto significa es básicamente verificar si el método de clase de servicio de la tienda de bonos de celda con el argumento 1020 fue realmente llamado. También podemos hacer otra cosa usando check. Y eso también está sugiriendo los tiempos de que se llama a estas funciones. Ahora, yendo un poco más a fondo en el conocimiento teórico verifica el método. Mockito puede realizar un seguimiento de todas las llamadas al método que haces en los métodos de prueba y también sus parámetros a objeto simulacro de deuda. Puedes hacer esto usando estos método de verificación que estoy hablando aquí mismo en el objeto simulacro. Como dije, es necesario utilizar esto verificar que se cumplan las condiciones especificadas. Por ejemplo, se puede verificar teóricamente que al método se le ha llamado ciertos parámetros es que estamos haciendo aquí en la línea 30 a este tipo de pruebas veces se llama pruebas conductuales. Eso es bastante sugerente. Y no comprueba el resultado de un método call buddy comprueba que se llame al método con los parámetros correctos. Como se puede ver en este verificar estados línea 3333, el resultado real, que es de 30 y debe ser 30 sobre método de deuda que se marca en ninguna parte que se encuentre, por lo que eso no está implicado en absoluto. El resultado de esa llamada al método, acabamos de comprobar si se llamó al método de profundidad o no con parámetros rojos y también el número de veces lo que se llamaba. Por supuesto, puede hacer muchas otras cosas que vamos a hacer, checar en conferencias posteriores. Pero en esta conferencia sólo vamos a concentrarnos en estos dos factores. Pasando por él de nuevo, los métodos refinados de juguete mono solo se utilizan para comprobar el cierto comportamiento ocurrido. Podemos usar estos métodos de verificación al final de los métodos de prueba y esa es la forma en que se debe usar como se puede ver en mi pantalla también. Para asegurarse de que en realidad se llamen a los métodos especificados que nosotros hacia arriba de ellos llamamos. De esta manera, tener otra forma de verificar que el flujo de trabajo real que sugerimos, este método de prueba realmente tuvo lugar y E está funcionando como pensamos que sería. Podemos seguir adelante y ejecutar esto y ver qué pasa con estas funciones de prueba. Al hacer clic derecho sobre el corredor de pruebas y ejecutarlo, se va a ir a la función principal. Entonces usando el núcleo JUnit, se va a ejecutar todas las clases en esta clase de prueba. Entonces va a iterar a través de cada una de las fallas si hay alguna, imprimirlas y si no, o incluso si fueran menos, VT va a imprimir en pantalla si el resultado fue exitoso o no. Exitoso, lo que significa que hubo algún error o no. Es bastante intuitivo cuando el método de clases de ejecución de núcleo JUnit se llama width la prueba de la aplicación de facturación. Nuestro método de prueba va a ser llamado. En primer lugar, agregamos el comportamiento del método de venta de servicio de tienda de empeño que se llama con el primer documento es Dan y el segundo argumento como 20, debe devolver 30. Ahora vamos a afirmar si el comportamiento se hace realmente afirmando si el método celular de esta interfaz y el valor real y el 30 son iguales. Entonces solo vamos a verificar si este método celular, bueno, en realidad se llama en línea 29. Y también vamos a comprobar si el método celular, los argumentos del inquilino 20, lo que también se llama onetime online 20. Cuando ejecutamos estos, como se puede ver aquí, dice que la tarea del corredor de pruebas Maine fue. Invocado, que fue esta tarea justo aquí. Tensión anticonfianza a verdadero. blanco resultó a verdad. Bueno, eso es porque iteró a través de todos estos años getfield y literalmente cumplió nueve años porque nuestro método de prueba no tuvo ningún fracaso. Y luego imprime que los resultados fueron exitosos. Estos lo que B es verdadero significa. Todo sucedió mientras plantamos aquí, se llamó a nuestro método celular. Se le llamó, de hecho, una vez. Ahora revisemos lo que pasa. Si queremos verificar si se llamó al método cell con los argumentos scan en 30. Si lo ejecutamos cada rodaje, háganos saber que no fue llamado con los valores 1030, sino los valores reales 1020. Y como se puede ver aquí en la prueba de tarea render main, dice que los argumentos son diferentes. Queríamos que los argumentos fueran 1030, pero la invocación real que ocurrió en la línea 29, tal y como se afirma aquí también, donde 1020. Por lo que nos especifica el fracaso en detalle como instruimos hacer en la prueba Turner en línea entonces entonces también nos imprime que el resultado no fue exitoso, por lo que fue falso. Ahora vamos a seguir revisando este 1020 para que deba devolverlo. De acuerdo, pero ahora vamos a verificar si la celda de método con el parámetro estándar 20 del objeto simulacro de tipo punch up service se llamaba en realidad dos veces. Por lo que de nuevo, debe advertirnos y debe volver falso cuando lo ejecutemos. Como se puede ver aquí, nuevo, devuelve falso. Y específicamente la deuda estadounidense, el método de prueba falló. Y la función celular de servicio de la tienda de empeño con estos parámetros estaba deseando ser llamada dos veces. Entonces eso es lo que queremos que suceda. Eso es lo que especificamos que pasaría. Pero en realidad el número de invocaciones, esa fue una vez. Esto bastante sencillo porque se llamaba Sólo una vez aquí en la línea 26 no se llama. Es sólo especificar que cuando Scott debes regresar 30. Por lo que esto no es en realidad una llamada a que ejecuta C. Verify método es extremadamente útil para podamos verificar que el flujo se especifica en nuestra prueba fue realmente ejecutado. No sólo que en realidad se llamaron los métodos a los que queremos que llamen, sino también las veces que se les llamó. El hecho de que especificara que esta profundidad, las cosas que salieron mal, vuelve a ser muy útil porque se puede ver a un nivel más profundo lo que salió mal exactamente. Y entonces puedes depurar con mucha facilidad, estás probando y ves qué pasa mal. Tal vez ya sea en su escritorio especificando lo incorrecto o en su método real. El método tiene muchas otras funciones complementarias reales como estos tiempos funcionan aquí mismo. Y vamos a correr a través ellos en detalle en las futuras conferencias. Pero para éste solo quería hacer rápidamente mostrarte nuestro Proyecto Set Up y también estas características de la verifica. Nuevamente, iterando a través de ellos que se llamó a la función con ciertos parámetros y los tiempos que iguala pidieron otras funciones que eran gratuitas con el método check en Mockito te suena interesante. Te sugiero que te quedes en las futuras conferencias. Y de nuevo, estoy muy agradecido de que te quedes conmigo hasta el final de éste. Espero verlos también en la siguiente. 9. Verifica la gama de llamadas de métodos: Hola chicos y bienvenidos de nuevo a este tutorial de marco de pruebas de Mockito, donde entendemos mejor cómo podemos usar este marco en particular con el fin de probar mejor nuestros métodos escritos en el lenguaje de programación de Java. En esta conferencia, vamos a seguir entendiendo el método verificar del marco Mockito, más a fondo. Y lo vas a hacer a través algunos otros métodos experimentales que pueden trabajar con estos método de verificación y también algunos otros métodos relacionados para verificar el método. El proyecto que estamos mirando, lo que se presenta en la última conferencia. Fue la de la aplicación de construcción con la superficie de la casa de empeño, el servicio de punzón de nuevo con la interfaz y la aplicación de construcción. Considerando que una clase concreta que estaba utilizando el servicio de casa de empeño en el método byte. La aplicación del edificio. Esta es la clase donde tenemos nuestras pruebas unitarias reales escritas, nosotros Mockito. Y esta es sólo una clase real que ejecutará todas las pruebas que tenemos. Algunos snarky es solo la aplicación de facturación después de clase. Y la última vez miramos el método check con el fin de verificar que se llamara a la función. Y además, miramos el método complementario de Times que estaba trabajando con verificar orden para verificar un número exacto de veces que se llamó a ese método. Pero más que estos tiempos funcionan, hay otras funciones complementarias que funciona con este método de verificación de Mockito y vuelven a ser muy útiles cuando queremos probar unitario nuestros métodos. Es útil de nuevo para comprobar com muchas veces se ejecutó método natural de vidrio que estamos probando. En primer lugar, es necesario recordar la sintaxis general de estos método de verificación, que es la palabra clave check. Y luego puede tomar como parámetros, en primer lugar, el objeto de la clase que se quiere probar en nuestra clase, es el mercado de la superficie de casas de empeño. Entonces puede tomar opcionalmente un segundo parámetro que es una función. Veremos qué hace esa función en un minuto. Pero después de estas verificaciones reales, verificar fechas de método el argumento sólo el objeto de Demócrito que queremos probar. Y luego la sintaxis especifica el método de esa clase con parámetros reales. Verifica no solo el método del gráfico que especificamos como primer parámetro, sino también sus parámetros. Ahora volver al segundo argumento es opcional, pero nuevamente darse en el método verificado. Especifica los tanques que esta función tenía costos reales pueden hacerlo. O puede ser tiempos. Y hablamos de esta última vez, como ya he dicho, que especifica cuántas veces se llamó ese método real con esos argumentos reales. Pero también puede ser al menos como máximo y la red al menos especifica si el objeto de clase como primer parámetro dado al método de verificación y su método con esos argumentos fue llamado en esta prueba al menos. Y entonces cada uno toma una integral en cuanto al número de centavos se llama o máxima célula. Se puede poner un límite aquí, pero no sólo eso, también podemos tener la función de red, que de nuevo es muy útil porque básicamente es lo opuesto a la función verifica simple verificar si se ha llamado a la función de la deuda. La segunda función de cortesía aquí, que nunca es asegura que el método de ese objeto en el que nunca se llamó a esos parámetros específicos. Además, que estas funciones de cortesía que podemos dar como parámetros verificados a lo largo del Ártico Dr. marcado vidrio. También tenemos el método verificar no más interacciones. Eso toma como parámetro el objeto simulacro. Lo que esto hace, verifica que todas las interacciones fueron verificadas. Se saca la causa real de los métodos con estos objetos de clases. Y verifica si todos esos costos verificados. Y si hay alguna interacción no verificada en estos objeto marcado, devolverá false al mismo. Especificaremos que como se puede ver en este punto, no hay interacciones no verificadas. Como el método celular es el único que se está llamando y en realidad se llama en línea. 29 es que me he puesto a la línea 39. No existe un método no verificado servicio de punzonado de objetos. Si realizamos la prueba en este punto, se puede ver que volverá verdadera y como todo se verifica. Pero luego en la línea 40, volví a llamar al método celular en el grupo objeto de servicio. Y esta vez voy a volver a escribir el verificar no más interacciones. Lo que hace esta función, verifica hasta el punto en que está escrita. Por lo que sólo antes de ella, si existen alguna interacción no verificada de métodos del objeto que recibe como parámetro 41. Ahora, vuelvo a especificar esta función solo que en línea 40, llamé al método del punzón de servicio. Como se puede ver, con los argumentos de 1020 DC es menos importante. Pero lo importante es que después de llamarlo, no lo verifiqué en absoluto. Entonces si corremos esto ahora mismo, cuando llegue a las muy finas direcciones normalmente aquí, sentirá que es falsa. Y como se puede ver, específicamente dice mucho detalle que saber direcciones donde una cuenta, línea 41, como dijimos específicamente con esta función. Pero encontramos la interacción del servicio de tienda de empeño simulada en 940. Y también adicional te mantendría para tu propia lista de referencia de todas las ubicaciones que se hicieron a estos objeto burlado en línea 40 no se verificó. En línea, lucha del miércoles 29. Y te dice que esta señal de aquí mismo significa que la implicación real no fue pelear. Como se puede ver la información en línea 40, que es ésta donde no se verifica. Y en línea 29, que es éste, fue verificado. Entonces allí no hay signo de interrogación. Entonces si además devuelve false, como recuerdas, ese fue el resultado de la línea 13 de si el resultado de la clase chimenea Corán del probador de aplicaciones de construcción de vidrio fue exitoso o no. Y en nuestro caso, no fue exitoso. Entonces esto fue al respecto para este tutorial donde volvimos a mirar algunos otros métodos complementarios sobre el método de verificación multidosis. Y también nos fijamos en la última más interacción con el fin de entender cómo funciona. En el siguiente tutorial, vamos a echar un vistazo al orden de los costos que se hacen y cómo podemos verificarlos también. Nuevamente, usando la palabra clave check. Si eso les suena interesante, espero verlos ahí. Una vez más. Gracias por quedarte conmigo. Después del final de esta conferencia. 10. La clase de InOrder: Hey chicos, y bienvenidos de nuevo a estos Mockito, Java unit testing framework tutorial, donde entendemos mejor cómo podemos probar unitario nuestros métodos escritos en el lenguaje de programación de Java. En esta conferencia, vamos a seguir hablando del método de verificación, el marco Mockito. Y más específicamente que eso, vamos a verificar en esta conferencia, el altar de invocación respecto a los métodos de entre objetos. En nuestra clase de pruebas. Podemos usarlo en clase de orden, como se puede ver aquí mismo, para verificar el orden de las invocaciones de diferentes métodos en nuestro objeto simulacro. En realidad podemos omitir algunos métodos que queríamos verificar. Pero los métodos que queremos verificar deben ser invocados en el orden para que puedas saltarte esta cadena, claro, en cualquier punto que quieras, pero la cadena desunada verificando necesita estar en el orden real que lo entregas al objeto en orden que creas. No se pueden omitir costos entre el costo que está tratando de hacer. Con el objeto en orden. Al mirar el código en la pantalla, se puede ver en la línea 40, como dije, declaré un objeto en orden de tipo en orden, que es una interfaz que está disponible en el framework Mockito. Y eso realmente tomará un tipo de objeto en orden, simulacro, el único parámetro. Y luego usando los objetos en orden que lo creamos, podemos invocarlo el método verificado que nuevamente está tomando, como sabemos, como primer parámetro, el objeto burlado que tenemos en la clase de prueba. Y puede tomar opcionalmente otro parámetro que especifique el número de veces que se ha realizado la llamada. Y ese es el disparate Phi. Tenemos la sintaxis que conocemos por ahora, dot la función que queríamos probar de obtener el código del objeto burlado y luego sus parámetros. Línea Sólida 41. Estoy muy bien con el objeto en orden, si se invocó la celda de servicio punch up con el argumento 20 y pruébalo después. Verifico si el método celular del grupo de servicio objeto con los argumentos entonces en 30 fue llamado dos veces. Y luego después de esto, estoy probando si se llamó al método bind con los argumentos de 1035 del grupo objeto de servicio. De nuevo estamos verificando el orden de las invocaciones del discurso en el mercado. Objeto con estos con el fin de clase y además, verificar el método. Como se puede ver, cambié un poco el código antes de esta llamada al método. Y en línea 30 tenemos la celda de servicio de la tienda de empeño con el argumento 20 celular. Este es el inicio de la verificación sobre las invocaciones de encadenamiento. Entonces tenemos en línea 35362 cos del método celular con los argumentos se hace en 30. Y se puede ver que eso es lo que estamos probando en la línea 42. Y luego por último en línea para D3, estamos probando si el método bind que documentamos estándar 35 fue llamado a continuación, que taxi era H puede ver en línea 35. momento, si manejamos esta clase, se puede ver que va a volver verdadero. Pero lo que sucede, por ejemplo, si en lugar de llamar al método con los argumentos, entonces en 35 lo llamaría documentos estándar 45. Con estos todavía funcionan bien teóricamente ahora se puede ver en la pantalla que no funciona. Y comer otra vez especifica en detalle, lo cual es característica muy útil que la verificación de inorder, fue fracaso y 35 método fue buscado pero no invocado. Fue buscado en cualquier parte después de la siguiente interacción, que es la 1030. Pero nunca se llamó a estas invocaciones reales. Ec2 está esperando el 1035, en realidad consiguió 45. Y el método de la función objeto de servicio con el argumento estándar cinco nunca fue realmente llamado en la secuencia. Este error falso se dio aquí. Esto fue al respecto con la función en orden disponible en el marco múltiple puede ser muy útil si desea verificar una secuencia de llamadas que realice en su clase de prueba. Espero que hayas sacado algo de este tutorial. Muchas gracias chicos por quedarse conmigo hasta el final de este tutorial. Y te veré en la siguiente. 11. Matchers de argumentos: Hola chicos y bienvenidos de nuevo al tutorial de pequeñas cetonas. En esta conferencia aquí mismo, vamos a discutir Mockito, emparejadores de argumentos y más específicamente ser Amy argumento matcher en el marco demo Quito. Estos son componentes muy importantes en el marco de Mockito y veremos por qué en tan solo un momento. Ahora metiendo un poco en las cosas de las que ya discutimos, Mockito nos permitió crear los objetos simulados y también agregarles comportamiento. La forma en que se agregó el comportamiento fue por las palabras clave cuándo y luego devolver la palabra clave, el objeto simulacro. Y recuerda que teníamos la palabra clave cuándo y luego parámetro tomó la función de objeto simulacro de deuda y también sus parámetros. Y luego la palabra clave return seguida del documento. Lo que ese método de los Objetos Marcados con esos parámetros específicos debe leer allí. Esa fue la forma en que Dinamarca. Añadamos comportamiento específico, comportamiento marcado, por supuesto, a nuestros objetos de mes solo para que podamos hacerlos devolver exactamente lo que queremos. Ahora, claro, hasta este punto donde se ve aquí algún doble, teníamos valores reales como ves estos sucios aquí mismo. Esa fue una forma bastante genérica de burlarse del comportamiento de un objeto simulacro. Pero los emparejadores de argumentos débiles tardíos de Mockito hacen una forma bonita, una sencilla, mucho más amplia básicamente dejarte marcar ese comportamiento. Supongamos que queríamos marcar el comportamiento para cualquier argumento del tipo dado. En ese caso, podemos usar esta matriz de argumentos de la que estoy hablando. Se definen en el Mockito, clase de matriz de argumentos y son métodos estáticos. Como ven, simplemente, podemos llamarlos aquí mismo. Hablamos cualquier objeto que esté relacionado con ellos. Podemos llamarlos por su cuenta. Como se puede ver, en lugar de realmente escribir valores específicos aquí, podemos escribir esta cualquier función doble. Y lo que esto hará, devolverá 34, en realidad, cualquier doble valor que se reciba como parámetros sobre el mismo método del servicio Objetos Marcados, LB de la clase de servicio. Y como pueden ver, hice un montón de afirmaciones aquí que tienen un montón de argumentos diferentes que son bastante diferentes entre sí. Y arriba por cada uno de ellos, especificé que debería devolver 30. Esta es solo una forma de probar que este comportamiento adulto aquí con el argumento importa en Mockito está realmente funcionando. Si hacemos clic derecho sobre él y hacemos clic en Ejecutar, vas a ver que para cada uno de estos métodos de celda con todos estos diferentes argumentos hacia fuera, estos métodos realmente devuelven 30, lo puedes ver devuelve verdadero. Si recuerdas que fue el resultado del método exitoso, el método de clase equivocado en el JUnit. Por el argumento de nuestra clase de prueba. En realidad funciona. Por lo que esta matriz de argumentos vuelve a ser muy útil, si quieres hacer simulacro de comportamiento general y ni siquiera te importan los argumentos que recibe la función. Por cualquier argumento que pueda recibir, solo quiere devolver el mismo resultado. Quizás porque quieres probar método y hay otro dentro de ese método y te fuiste al mercado. Por lo que solo quieres comer esa función y no hay otras funciones. Y si hay alguna otra función, te fuiste a burlarse de ellas para devolver valor estético, que en este caso sería, como ya he dicho, 30. Y en este escenario, las deudas son algo bastante valioso que Mockito te permite hacer, además del método doble N. Por supuesto que tenemos alguna comer cualquier booleano y así sucesivamente. Por cada tipo de datos que se pueda pensar, cualquier método, puede reemplazar cualquier tipo de datos que pueda darse como argumento para el método Where. Pero muchas gracias chicos por seguir conmigo hasta el final de esta conferencia. Y en la siguiente, vamos a discutir los espías. Dentro del marco de Mockito, vamos a echar un vistazo a qué son exactamente y cómo pueden ser útiles para preguntar cuándo unidad prueba nuestros métodos. Entonces eso te suena interesante. Espero veros chicos. Ahí. 12. Spies: Hola chicos y bienvenidos de nuevo a estos tutorial de Mockito, donde entendemos mejor cómo podemos probar unitario nuestros métodos escritos en el lenguaje de programación Java. En esta conferencia, vamos a discutir sobre Spice, marco de Mockito. Y también entender qué son exactamente y cómo pueden ser útiles en un viaje. Para escribir estas pruebas unitarias, podemos usar un espía de Mockito para burlarse parcialmente de un objeto. Parcialmente burlarse de un objeto es burlarse de objeto de deuda. Pero cuando creamos ese espía realmente fuera de un objeto, se llaman esos métodos reales de los objetos, pesar de que se trata de un objeto simulacro. Ahora, tengo en pantalla una implementación que será un gran ejemplo para esta definición y te ayudará a entender exactamente qué son las Spice. Está familiarizado con este proyecto en Intel J, no habíamos construido la aplicación aquí. Y también se burlan de objeto. El objeto simulacro fue inyectado en el edificio la aplicación, que en realidad era un método concreto. Ahora en nuestro método de prueba, en primer lugar, añadí el comportamiento de que el servicio de la tienda de empeño, que era el objeto marcado en caso de que al método celular de la misma se llamara al método celular de la mismacon dos duplica lo que sea, Es argumentos entonces H2, H3, pluma sucia. Ahora lo que hicieron, declaré un objeto de tipo de aplicación de facturación, y le asigno un espía en el objeto de aplicación de facturación. Entonces lo que hice, llamé a este objeto pastel el método cell, width, los argumentos de 1020. Clase de aplicación de facturación muerta. El método celular. Lo tenía implementado para que regresara e imprimirlo en pantalla, la suma de los dos números que se dan como parámetros. Después de eso, también creé un objeto de tipo casa de empeño servicio en línea 34, y están asignados para comer el SPI del objeto de servicio de la tienda de empeño. Ese fue en realidad el objeto burlado en esta clase de pruebas. Y lo que hicieron. Además, imprimimos el método celular de este objeto espía con los 2323 argumentos. Si esto no fuera un espía en el servicio de la casa de empeño, debería devolver 30 porque eso es lo que hacemos. Si el método celular del objeto de servicio de la tienda de empeño se llama con dos dobles, entonces debe por defecto, devolver 302223 son dos dobles. Y cuando ejecutamos esto, se puede ver que en primer lugar, éste devuelve 30. Porque entonces y 20 es 30. Y específicamente estrictamente para imprimir en pantalla la suma de los dos parámetros. Además, devuelve 0. ¿ Y por qué está volviendo eso 0? Porque el objeto de servicio punch up es en realidad de un simulacro de vidrio, que era solo una interfaz. Y el método cell no está realmente implementado, por lo que devuelve el doble predeterminado, que es 0. Si esto no era un espía, y en realidad teníamos aquí en lugar de SPI al servicio de la casa de empeños. Se puede ver que por defecto devolverá 30. Como se puede ver aquí, porque eso es lo que el comportamiento de éste entonces devuelve declaración no tiene que hacer. Entonces. Esa es la diferencia entre un objeto marcado con comportamiento ADD y un objeto espía sin marcar. El espía del objeto simulacro en realidad llamará el método real de ese objeto. También podemos usar en lugar de la clase Spy para llamar método real, método en un objeto marcado para llamar al método real. Esa también es una variante aquí, pero no se recomienda y se recomienda utilizar un espía para estas marcas parciales. Y la razón principal de eso es porque espiar que los pollos que tenemos es en realidad instanciado. Cuando creamos un objeto simulacro, el mono TO crea una instancia de un objeto, que más o menos sólo el esqueleto del mismo. Entonces con el mínimo desnudo, y puede haber una posibilidad de que esas dependencias requeridas no se inicialicen cuando se esté creando el mercado con el Mockito. Y esto puede llevar a malos resultados al final. Y es por eso que las especias son realmente preferidas en lugar del método de código a continuación, método que también está disponible en este contexto. Por eso espero que ustedes sacaran algo de este tutorial y entendieran qué son los espías y cómo pueden ser útiles para nosotros. Gracias de nuevo por seguir conmigo hasta el final de esta conferencia. Y espero veros chicos en la siguiente.