MOCK en UNIT TEST para tratar con DEPENDENCIAS EN C#
Vložit
- čas přidán 24. 07. 2024
- En este video veremos como trabajar con las dependencias a otras aplicaciones o servicios dentro de nuestros test unitarios
Si te gusta el contenido, puedes apoyar al canal invitandome a un café www.buymeacoffee.com/netmentor
00:00 🧩 Testing con mocks en C#
- Explicación sobre la necesidad de utilizar mocks en pruebas unitarias,
- Uso de mocks para simular dependencias externas como llamadas a bases de datos o servicios externos,
- Introducción a la librería Moq y su aplicación para simular interfaces en pruebas unitarias.
03:41 🛠️ Instalación y configuración de Moq
- Instalación de la librería Moq utilizando NuGet,
- Configuración básica de Moq para simular interfaces,
- Descripción de los parámetros principales de Moq: Setup, Returns y Verify.
07:20 🏗️ Implementación de pruebas con Moq
- Creación de pruebas unitarias utilizando Moq para simular interfaces,
- Ejemplo práctico de creación de pruebas para un servicio de gestión de artículos,
- Uso de Setup, Returns y Verify en las pruebas unitarias para garantizar su funcionamiento correcto. - Věda a technologie
twitter: twitter.com/NetMentorTW
Blog: www.netmentor.es/Entrada/mock-unit-test-csharp
muchas gracias, me salvaste, estaba depurando un test con moq y no tenia idea de como funcionaba, gracias por compartir tus conocimientos.saludos.
🎯 Key Takeaways for quick navigation:
00:00 🧩 *Testing con mocks en C#*
- Explicación sobre la necesidad de utilizar mocks en pruebas unitarias,
- Uso de mocks para simular dependencias externas como llamadas a bases de datos o servicios externos,
- Introducción a la librería Moq y su aplicación para simular interfaces en pruebas unitarias.
03:41 🛠️ *Instalación y configuración de Moq*
- Instalación de la librería Moq utilizando NuGet,
- Configuración básica de Moq para simular interfaces,
- Descripción de los parámetros principales de Moq: Setup, Returns y Verify.
07:20 🏗️ *Implementación de pruebas con Moq*
- Creación de pruebas unitarias utilizando Moq para simular interfaces,
- Ejemplo práctico de creación de pruebas para un servicio de gestión de artículos,
- Uso de Setup, Returns y Verify en las pruebas unitarias para garantizar su funcionamiento correcto.
Made with HARPA AI
Soy nuevo con éste paradigma y en la oficina justo lo usan así; espero que nos sigas regalando más material. Gracias
Gracias por enseñarnos a usar esta herramienta, no todo los héroes usan capa
Muchas gracias me ayudo a comprender mucho mejor el tema 🤗
buenas noches, si en el "returns(value)" necesito retornar un objeto que por x razón su constructor no es publico. como seria la mejor forma. gracias por el video
si su constructor no es público, como se construye? a través de factory method (un metodo estático llamado "create" o similar) ? deberías usar ese método.
Pero depende un poco de como sea. Si el constructor es protected, puedes crear una clase (solo para el test) que herede de la que quires devolver y crear el constructor ahi, llamando al constructor del padre.
Si es internal vas a tener que modificar el objeto o incluso abstraerlo
Otra opción es si el objeto implementa una interfaz puedes crear otro objeto que implemente dicha interfaz, pero esto ya depende de la lógica.
Un saludo!
No termino de entender como funciona el Setup del Mock, a => a.GetArticulo(1), que significa eso? que cuando se llame al método GetArticulo del Mock con el valor 1 devuelve lo que indica Returns?
Si, exactamente eso
@@NetMentor Ah bueno, me parece raro, gracias por contestar!
Hola net sabes como hago cuando se utiliza el repositorio una interface genérica y un repositorio genérico y los repositorios individuales heredan de estos me podrías ayudar porfavor
vas a tener que explicarte mejor
Como tratar de hacer el test cuando se devuelve un objeto diferente al que se tiene en el parametro de entrada ejemplo, en el parametro de entrada tenemos un DTO, y devuelve una entidad diferente, como se puede hacer en el mock usando mapper
Simplemente en el return del mock pones el objeto que quieres devolver.
No se si te refieres a eso. Si me mandas un link de GitHub con el ejemplo lo puedo mirar.
Un saludo
tantas líneas de código para n programador independiente q hago solo todo el proyecto creo q no aplica excepto q en funcionalidades q me sean complejas puedo aplicarlo
Te refieres a los test en general? Los test de integración podría pasar no hacerlos en algunas circunstancias, pero los unitarios son obligatorios para asegurarnos que el código funciona y no hace cosas raras, tanto ahora, o si lo modificamos en varios años
La capa de dominio no debería solo resolver negocio 🤔 o varía según la arquitectura que se use 🤔, buen vídeo 🇲🇽
a que te refieres con "solo negocio"?
Este ejemplo es pequeño por lo que está bien así, pero por ejemplo.
Si tienes varios "project library" en tu proyecto cada uno de estos project library debería tener sus propias dependencias y ser testeados individualmente, no en grupo.
no se si me explico, es algo complicado explicar esto sin ninguna imágen :/
El "Servicio" que se encuentra en Dominio, es justamente el que se encarga de resolver el Negocio... manipulando los datos obtenidos desde la capa de datos. (IRepository)
@@juanmarcosvallejo3800 sip, pero solo debería tratar con los datos obtenidos, esas implementaciones del repositorio debería ser en la capa de aplicación y pasar dichos datos a dominio. Aunque he visto que las implementaciones de estos varía según el arquetipo dónde se trabaje!)
Buenas tardes Net Mentor, ¿Se puede hacer mock de metodos estaticos?
Se puede, puedes utilizar shims
docs.microsoft.com/en-us/visualstudio/test/using-shims-to-isolate-your-application-from-other-assemblies-for-unit-testing?view=vs-2019#static-methods
Pero por norma general no se suele hacer mock, al menos en mi experiencia .
Un saludo !
Como seria un MOCK list de un GetAll() metodo por ejemplo, no se si me explico
Simplemente tienes que poner en el return la lista
Hola NerMentor agradezco la atencion que puedas prestarme, soy desarrollador y me han solicitado que haga pruebas a lo que vaya desarrollando, te pongo un ejemplo tengo un controlador para radicar una solicitud algo compleja ya que uso VieModels para llenar listas y cosas, un CRUD pero con objetos complejos, en el controlador en el constructor inyecto(ApplicationDbcontext, Unidad de trabajo, Logger) entre otras cosas que voy necesitando en cada controlador no se como hacerlo ya que tengo varias capas y al final los datos los saco o guardo con la UnidadDeTrabajo que dentro tiene una implementacion de repositorios que se crean en otra capa y esa capa hace extraccion de la capa de DomainModel no se si me hago entender pero es complejo para mi y no se si como desarrollador deberia decir que no son competencias mias o como deberia hacerlo agradezco tu ayuda
Es totalmente parte de tu trabajo, te recomiendo que preguntes a otros miembros del equipo como hacéis los test, para saber si tienes que hacer unitarios, de integración o ambos.
Si no hay nadie que te pueda enseñar tienes que pedir un proyecto que los tenga y más o menos hacer lo mismo.
Un saludo.
Hola, sin mock que podrías utilizar?
sin usar mock, puedes hacer dos cosas, ambas empiezan por crear una clase que implementa la interfaz que quieres inyectar, y luego:
o bien "recreas la clase" por ejemplo, si es una base de datos, y tienes un método "insertar" lo que haces es tener una lista y en el método insertar añades a esa lista, en el de consular consultas de esa lista, etc. esto se llama "fake".
y la alternativa es que siempre devuelvas el mismo valor, da igual qué es lo que venga como parámetros, siempre devuelves el mismo valor (hardcodeado por ti) dentro de la clase que creas. Esto se llama stub.
Un saludo!
Bueno.. bien.. una introducción, pero deberías de explicar aunque parezca una tontería el concepto AAA para hacer las P.U con idea.. otra cosa es que las pruebas son de comportamiento y si SOLO vas a comprobar un dato, informa de ese dato, no del resto ... con poco código, no se nota, pero cuando te enfrentas a codelegacy y métodos grandes, no veas como intentar hacer bien una P.U simple... (todo va relacionado con el AAA y el assert es el que da el resultado, por eso cuanto más concreto la info, mejor). :P
pero que estarías testeando acá, si estás hardcodeando todo?
si desconoces como funcionan los test te recomiendo que empieces por el principio czcams.com/video/MSRoRRX4qHg/video.html un saludo!
Desde la ignorancia, ¿Esto es viable en servicios/Repositorios que utilizan muchas tablas por sus relaciones?, no veo viable crear un Mock para un objeto que tiene muchisimas relaciones y que además sean coherentes, y que no sean "inventados"(que sería imitar/Mockear). No se si se entendio, que si se tocan muchas tablas en un mismo metodo, es mucho más el tiempo que vamos a estar escribiendo código. Es la primera vez que leo sobre "Mock", por eso la duda. ¿Tenes otro video más avanzado de este tema?, porque generalmente los ejemplos son básicos, y con razón, porque son para entender el tema.
La idea es hacer mock del reposotiro, si quieres comprobar que la lógica que tienes en la capa de repositorio funciona lo que necesitas es un test de integración.
El tema está en que si el.codigo en el.que trabajas es un follón de cuidado, con todo interconectado y que no se puede separar, es muy difícil hacer bien los tes y la gente pasa a los de integración directamente. Este tipo de situaciones se ven mucho en código antiguo o en monolitos que no se han cuidado
@@NetMentor Gracias por la respuesta, creo que entiendo a lo que se quiere llegar con esto, ya veré si me es viable utilizar "Mock". Un saludo.
No hay una forma en que el inyector resuelva las dependencias y no tener que "mockear" las dependencias de repository, solo mocker los servicios y el inyector resueva el resto?
La Cosa es que durante los test unitarios no tienes contenedor de dependencias así que no hay forma de que lo resuelva solo.
Si haces tests de APIs entonces si tienes un contenedor de dependencias y puedes especificar lo que quieres mockear y lo que no
czcams.com/video/mUceQgGoKC4/video.html
Un saludo
@@NetMentor Gracias crack!! una pena que no se pueda acceder al inyector y poder remover la implementacion con el Mock/Stub creado
por que la prueba es sobre el dominio en vez que sea sobre el api como tal?
la idea de los test unitarios no es cubrir el 99% del cóigo, sino de cubir las partes de lógica lo mejor posible, en este caso, es recomendable cubrir el la capa de logica de la aplicación con múltiples test que dan diferentes salidas mas que un test a la api.
Cuanto mas concreto sea un test mejor, una "api" cubre mucho, mientras que un "caso de uso" es eso, un caso de uso.
normalmente los test a la api son mas dificil y complejos de hacer. Hré un vídeo "pronto" sobre como hacer test al endpoint.
@@NetMentor luego de darle vueltas un par de días me quedo claro el concepto. gracias
Según entiendo Mock es más bien un Simulacro. Que es lo que estamos haciendo
Te refieres a la traducción directa? Posiblemente simular tenga mas sentido y sea la apropiada, pero da la sensación que la traducción no está adaptada al siglo 21 😂
@@NetMentor En ingles igual que en nuestro idioma hay palabras que son sinónimos y la verdad después de investigar fue la mejor traducción encontré de acuerdo a nuestro trabajo.