1:38
2025-03-19 13:02:19
5:09
2025-03-20 09:04:50
1:01:32
2025-03-20 09:32:49
4:31
2025-03-20 09:35:15
31:01
2025-03-20 10:19:57
17:34
2025-03-20 15:02:37
Visit the Agile Software Testing course recordings page
WEBVTT
-->
acceder a la url, por ahi veo que no, ella lo esta descargando, ahi es mas que pudo descargarlo
-->
ahi también creo que ya lo esta descargando, ah ya lo descargo, excelente
-->
justo lo que esta haciendo la mahi es lo correcto, una vez que ya tengan el nuevo archivo, bueno
-->
la nueva carpeta, hay que volver a eliminar los contenedores y crearlos con el contenido
-->
que tenemos ahi en el laboro que el compos, creo que es el mismo, pero bueno, no esta
-->
de mas eliminarlos y nos volvemos a recrear, cuando puedan acceder al contenedor de .net
-->
me avisan, ahi es donde hacemos la pauta y les vuelvo a mostrar como ejecutar el
-->
contenedor, mientras en lo que eso sucede, y ahi que me avisen, yo voy a ver si ya
-->
levanto, ya me levanto la, entonces excelente, ahi dejamos el code share, para futuras referencias
-->
y por cierto ustedes tienen en sus, en su empresa restricciones como de firewalls, reglas,
-->
no se, por ahi de que les impida descargar docker o algo asi, o son libres de ambientar
-->
ah, externo, si me imagino, ahi hagan su peticion colectiva para que les, entremos
-->
por favor al de punto en excelente, y una vez que estes ahi adentro amigo, ya ahi
-->
me espera, va, me avisa a escribir, lo puedes colocar en donde tu quieras, yo te recomiendo
-->
que literal reemplaces la carpeta que existia por la nueva, que creo que esta
-->
en el escritorio si no mal recuerdo, si esta en el escritorio, ahi tal cual, reemplazala
-->
ahi la duda que pregunto, ahi pues realmente es valida, tu lo puedes poner en donde tu
-->
quieras, lo unico importante es asegurarnos de que cuando corramos el comando docker
-->
compose op, accedamos obviamente a la ruta en donde esta el archivo docker compose,
-->
entonces no importa la ruta, lo que importa es en donde va a estar, que se ejecute
-->
dentro de ese mismo archivo
-->
y en todos, quien mas, ademas de noe, sergio ya tambien ahi tiene, el ios ya esta dentro
-->
del container, perfecto, ya nada mas nos falta el glasio, bien ahi, vamos a usar
-->
ahi un par de minutitos mas, y ya le seguimos, y en caso de que a ustedes les
-->
quepo este, ahi ahorita hacemos otra, listo ahi tambien ya esta, y ahi nacional nos
-->
le falta por ahi un comando, excelente, bueno vamos a continuar, entonces otra vez
-->
por favor me ayudan poniendome atención a mi, les voy a mostrar como levantamos
-->
el api y ahorita lo hacen ya en su maquina, basicamente para levantar el api es una
-->
vez que yo ya me meti al contenedor, si, yo voy a estar adentro de la carpeta
-->
workspace, cuando ustedes entran, lo que hay que hacer es meternos un nivel mas adentro
-->
y nos vamos a meter a la carpeta msdemo, porque ahi adentro esta todo nuestro
-->
aplicacion, entonces le dan cd msdemo y obviamente adentro del contenedor
-->
y ya que esten ahi adentro ya vamos a poder ejecutar los comandos que les voy a
-->
mostrar, los voy a señalar, en la nueva hoja de chuleta que ustedes ya tienen
-->
ya obviamente van a tener la version mas reciente, la ultima, van a ver una, perdon
-->
un bloque de código que esta en la linea 86, en la linea de la 86 a la 92
-->
basicamente pueden seleccionar todos esos comandos, les van a copiar y los
-->
ejecutan dentro de la carpeta que les acabo de comentar, que es la msdemo
-->
estan ahi, simplemente le han clic derecho, pegar y ya, en automatico
-->
si lo hacen como les dije, pues es mas comodo, los comandos se van a
-->
ejecutando secuencialmente, va, entonces
-->
que hacen estos comandos, basicamente van a borrar
-->
van a recrear la cachet, van a quitar el obj, van a quitar de las pruebas
-->
tambien ese obj, van a hacerle una limpieza, van a hacer un restore
-->
van a hacer nuevamente un build, y despues de que hagan ese build
-->
ya van a poder ejecutar con el comando .net run
-->
la url que se encuentra en localhost
-->
en el puerto 5000, vamos a hacer una aclaracion respecto a esto
-->
esto de aqui, quiere decir que corra localhost
-->
en el, es la direccion host interna
-->
de la maquina, si, por eso es que lo detecta, cuando yo
-->
ejecuto este comando estoy adentro del contenedor, y obviamente pues dentro
-->
del contenedor localhost se llama asi 0.0.0.0
-->
y que puerto quiero que exponga, el 5000
-->
como nosotros ya habiamos visto aqui en el compose
-->
si, estamos ahora accediendo a este puerto que acabo de seleccionar
-->
al de la derecha, ese puerto que esta, que ahi acabo de mover
-->
ese puerto, es el que esta dentro de la maquina
-->
por eso es que yo lo necesito exponer en ese puerto, para que
-->
al externo tambien pueda acceder al mismo puerto 5000
-->
y me haga el match con la aplicacion, sale
-->
entonces si quieren ayuden a ejecutar estos comandos
-->
y finalmente vemos la, bueno, vamos a ver el ultimo paso
-->
una vez que corren esos comandos, lo unico que hay que hacer es acceder al
-->
endpoint que yo le llame como de health check
-->
que ese endpoint es basicamente el de la aplicacion
-->
que tenia por default.net, lo vamos a copiar en la linea 100
-->
vamos a pegar eso en un navegador, si, le vamos a dar
-->
pegar e ir, y con eso van a ver esta respuesta
-->
una vez que ustedes tengan esa respuesta ya con eso vamos a poder continuar
-->
pero basicamente esto nos estaria diciendo que ya esta arriba
-->
el backend, si, esa es la respuesta que ustedes deberian de tener
-->
como salir, entonces si quieren ayudenme
-->
porfa a llevar esos comandos y
-->
le vamos continuar, sale
-->
esto es lo que van a ver en la salida de la consola cuando ejecutan los comandos
-->
ustedes tienen que ver esta parte, vale, no se si tienen
-->
alguna duda o pregunta, si no, adelante pueden ir haciendo
-->
la ejecucion de comandos, y yo mientras los voy a ir
-->
monitoreando, por ahi Sergio veo que ya tiene
-->
la respuesta del API, bueno del API
-->
que viene por default
-->
tambien el yot, perfecto
-->
los demas tambien ya van mas o menos, ahi tambien Anaia lo tiene
-->
excelente, muy bien, excelente, tambien no ella
-->
pudo ejecutar el endpoint
-->
perfecto, y vamos a ver
-->
ahi Ignacio te falta ejecutar el ultimo comando
-->
porque ahi exacto, a ver dejame ver si puedo ver en tu maquina
-->
ah listo, si ya lo ejecutaste, ahi hay que, es que como que el bloque
-->
no ejecuta el ultimo, entonces el unico, me falta decirles el ultimo
-->
exacto, y entonces Ignacio ya tambien ahi lo tienes
-->
entonces ya todos estamos a la par, ya todos tenemos eso, entonces ahora
-->
para poder yo entrar a la API que ahorita
-->
desblozamos o que destazamos, que fue la del login
-->
lo unico que hay que hacer es meternos nuevamente aqui en la chuleta
-->
y aqui van a ver un, dejame ver si tienen el post
-->
ahi no lo tienen, ok, lo que vamos a hacer es
-->
vamos a abrir postman, ustedes deben de tener postman ahi instalado
-->
abranlo por favor y ahorita yo les voy a pasar el call
-->
para que lo puedan importar y podamos hacer la peticion
-->
pero desde postman, si, entonces yo ahorita se las estoy mostrando ahi
-->
si se fijan ya interactue y pude probarla
-->
entonces simplemente es copiar este call y se los voy a pasar
-->
dejenme ver si ya lo puedo volver a pegar aca y si no se los pego
-->
en el mismo code shell que teniamos ahi este
-->
trabajando, parece que no, no, no se ve pegando
-->
esta bien raro, no se porque todo el tiempo ayer estuve
-->
ah perfecto
-->
ah ya tienen el login ahi, ah pues si se quedo perfecto
-->
entonces si quieres haganle post
-->
y diganme si pueden, si si les esta respondiendo el login
-->
excelente, perfecto, muy bien
-->
entonces interactuen ahi con la, con el API por favor
-->
manden por ejemplo un admin 1,2,3,4,5
-->
y vean que sucede, manden parametros vacios
-->
no se, esto que vamos a estar haciendo es un primer
-->
modo de prueba, aqui es como si estuviéramos haciendo una prueba manual
-->
eh obviamente aqui vamos a hacer una pauta
-->
para explicar un poquito el escenario de este
-->
primero voy a hacer la pregunta, quienes ya trabajaban con postman?
-->
quienes si lo conocen? yo me imagino que la mayoría
-->
pero no se, si todos? ok perfecto
-->
bien entonces eh
-->
pues eso ahi, ahi postman es un cliente que nos permite
-->
interactuar con las APIs si, eh hacer peticiones tanto
-->
res como swap, eh también del tipo gRPC
-->
draftql, ese tipo de peticiones no, en este caso
-->
estamos haciendo algo muy sencillo con pulltonet, no que es como
-->
su número mole y listo, estamos ahi haciendo pruebas
-->
perfecto entonces
-->
ya logramos hacer la peticion ya tenemos con esto nuestro
-->
ambiente de backend encendido, ahora vamos
-->
a revisar la parte del front, vamos a revisar como esta construido
-->
un formulario de login y como finalmente se
-->
conecta con este backend para interactuar
-->
para eso yo eh obviamente aqui ya tengo
-->
el formulario corriendo si, si ustedes
-->
acceden a la misma url que yo que por ahi tambien la chuleta se encuentra
-->
es el localhost 5000 diagonal login y con eso van a poder
-->
renderizar este formulario si, este formulario vamos a
-->
ver como se desarrolla, pero basicamente es un formulario
-->
chiquito es lo que les decía en aplicacion en la cual eh yo tengo ahi
-->
un campo email, un campo password, pequeño formato ahi de estilos
-->
eh y listo, voy a poder ejecutar aqui
-->
emails, voy a poder poner mas bien algo
-->
una peticion y voy a poder enviarlo ahi bueno ahi nos sale un
-->
define, hay algo que corregir, sin embargo bueno la idea es que
-->
existan estas validaciones, yo ya tengo
-->
esto, ya tengo esto, si te fijas ya cuando mando
-->
el formato correcto eh pues la
-->
la, el mensaje es correcto, justo por esto
-->
es porque yo necesito de hecho bueno creo que salio
-->
salio sin querer respecto a que eso era mas bien una practica
-->
para ustedes detectar eh como testers digamos
-->
posibles mejoras o cambios o errores dentro del aplicativo, pero bueno
-->
ya no importa ya salio aqui, el eh aqui por ejemplo nosotros podemos
-->
debatir que una persona cuando este probando que tipo
-->
de hecho aqui vamos a empezar a hacer una serie de debates, preguntas
-->
aqui por favor ayuden a participar, que tipo de pruebas ustedes
-->
como testers se les ocurre que podriamos hacerle a este pequeño formulario
-->
vamos a ir repasando las
-->
los escenarios conforme a lo que hemos visto un poco de teoria
-->
eh no se aqui lo que quiero es ver un poquito es
-->
el entrenamiento de que todos tengamos como un panorama
-->
de que se podria probar en una aplicacion del tipo login
-->
quien quisiera empezar a darme ahi como su opinion
-->
quien tiene una nocion, quien cree que pueda definir ahi como
-->
algunos, algunas pruebas que se puedan hacer
-->
y ademas ayudenme por favor a categorizarla
-->
ya sea que sea una prueba funcional o una prueba no funcional
-->
sale, entonces esto es un ejercicio, es una practica
-->
quien quisiera comenzar, bueno para empezar no se si ya todos pudieron correr el login
-->
si, excelente, que te parece si empiezas tu Noe
-->
que abriste ahi el microfono
-->
que te parece si tu me das una prueba funcional
-->
recordando el concepto de ayer de la prueba funcional
-->
no se si te queda ahi el nombre, recuerda
-->
cual es una prueba funcional por ejemplo
-->
de que nos los ha llenado
-->
claro, claro, excelente, eso que mencionaste
-->
es una prueba funcional porque debe de funcionar tal cual
-->
como estas diciendo que no permita el envio
-->
de campos que no estan vacios, te voy a hacer una
-->
pregunta bueno, si no estan llenos claro
-->
esa es una, que fíjate que ahi a lo mejor en términos de UX
-->
eso lo aprendí de un UX precisamente
-->
me decía que es mejor dejárselo habilitado porque si yo se los deshabilito
-->
la persona piensa que no sirve el botón y va a decir
-->
bueno y como lo habilito y no hay una forma de que el entienda que tiene que llenar los campos
-->
entonces la idea es como dejar que interactue
-->
y sea la interfaz la que le diga que esta pasando
-->
eso que acabamos de tener ahorita entre nosotros
-->
es un dialogo de que estamos poniéndonos de acuerdo
-->
en definir una funcionalidad que es lo que ayer veíamos
-->
stakeholders se ponen, se reúnen y empiezan a hacer una lluvia de ideas
-->
de decir bueno yo en otros lados he visto que se prueba asi, no yo en otros lados
-->
veo que si, y de nuestras ideas sale un parte aguas, una regla de negocio
-->
que va a dictar unas en la metodología de ahi
-->
cuando creamos nuestro backlog van a hacer un requerimiento
-->
funcional y ahi ya no va a haber un dime si diretes
-->
ahi se va a ir la regla tal cual y decir no
-->
esto va a estar deshabilitado y solamente se va a habilitar cuando el usuario
-->
llene los campos o como dijo diego va a estar
-->
va a estar el botón siempre prendido para que el usuario la riegue
-->
y la interfaz interactue con el, aqui le pude haber mandado un mensaje en vez de
-->
decirle llename los campos o no hay campos vacios
-->
una validacion, no se, sale, esto
-->
ahora, muy bien noe, muchisimas gracias por tu participacion
-->
ahora yo les voy a hacer a alguien mas con una pregunta y ese alguien va a ser
-->
eliot, eliot te voy a preguntar
-->
eso que dijo noe
-->
respecto al tema de poder validar
-->
los campos a ti
-->
te suena que es una validacion que va del lado del frontend o del lado del back
-->
de que no sean
-->
que no esten vacios, lo que explico noe
-->
noe dijo yo aqui podria probar que estos no me los dejen vacios
-->
a ti
-->
perfecto
-->
excelente
-->
alguien, alguien opina
-->
diferente, alguien tiene otra idea, vamos a ir haciendo un ejercicio
-->
yo voy a ir levantando los requerimientos, sale, el primero es validar
-->
campos nulos, ya salio
-->
nuestra idea, dentro de esos campos nulos
-->
yo pregunto
-->
va del lado del front o del back
-->
y ya eliot nos dijo que a el se le hace muy buena idea
-->
levantarlos tanto del front como del back
-->
si te fijas voy poniendo una lista de lo que vamos a
-->
tener que hacer porque esto es lo que le vamos a pasar al programador
-->
nosotros estamos ahorita en un rol de testers
-->
y nosotros estamos definiendo que es lo que se le debe
-->
de validar a los campos, aqui hay una primer validacion muy buena
-->
que es campos nulos
-->
una persona por ahi nos dijo que es eliot tanto en el front como en el back
-->
alguien opina igual, opina diferente
-->
todos estamos de acuerdo en que se debe validar tanto en el front como en el back
-->
excelente, yo tambien
-->
si me piden eso yo diria que esa validacion debe de ser
-->
tanto en el front como en el back, porque si yo
-->
hago modular mi software si mi back se lo puedo llevar
-->
a cualquier otra interfaz el servicio debe funcionar igual
-->
si yo mando información erronea
-->
debe de validarse, eso es lo que podemos probar
-->
si te fijas ahorita ya lo hicimos, aqui en el front no funciono
-->
entonces ahi ya tendremos que levantar un error
-->
no funciono el tema de los campos nulos, pero en el backend
-->
vamos a ver que pasa, si yo mandara un campo nulo que me diria ahi la aplicacion
-->
ahi me esta diciendo una decepcion
-->
y me esta diciendo una validacion fallo, un status 400 y me dice
-->
la contraseña es obligatoria, esta validandome el campo
-->
que no sea nulo, se me explico, entonces
-->
en el backend funciona, parece que si
-->
como me cercioro finalmente, ah pues no se
-->
voy a ver tambien si el email lo valida, exacto, y ahi me dice
-->
no es valido, me esta haciendo dos validaciones, eso es por el
-->
modelo que ahorita vamos a revisar, pero bueno al final a nosotros como
-->
testers nos importa que la aplicacion este funcionando, aqui
-->
pues estamos viendo como testers ya le estamos haciendo pruebas
-->
y pues estoy diciendo que digamos la aplicacion
-->
conforme a la idea que ustedes ahorita que
-->
ustedes le estan levantando los requerimientos
-->
esta funcionando, entonces en el backend parece que si funciona, en el front
-->
no, esto es porque vamos a levantar tareas en gira
-->
le vamos a ir asignando a un desarrollador, que es lo que
-->
vimos como en nuestras pruebas que esta pasando
-->
estamos haciendo testings, sale
-->
le estamos diciendo, es una pantalla muy
-->
sencilla, pues ahi le vamos a decir que es lo que esta fallando, sale
-->
nosotros ahorita estamos haciendo una validacion, una lluvia
-->
de ideas, digamos con un minimo de orden
-->
pero otra estructura podria ser separarlo por funcionalidad, por ejemplo
-->
yo puedo listar el frontend, todo lo que
-->
encuentre, y dentro del backend igual, puedo agarrar el backend
-->
y aqui empezar a hacer todas las validaciones que se me ocurran
-->
o todo el analisis que se me ocurra, cualquiera de los dos enfoques es bueno
-->
el chiste es tener orden, e incluso ustedes pueden tener un template mas adelante
-->
que les permita levantar esos requerimientos
-->
y todo nace a traves de que ustedes estan haciendo
-->
una observacion y de la expertise que tienen del sentido
-->
comun, etc, etc, todo esto es lo que se escucha
-->
ahora
-->
a quien creen que le podemos preguntar
-->
que tipo de mensajes vamos a manejar
-->
para que la aplicacion responda de forma
-->
adecuada, o le notifique al usuario de
-->
forma adecuada, que se comunique con el usuario
-->
la parte de que los campos nos tambien
-->
vamos a suponer que aqui no sale un define y que sale el mensaje de campos
-->
son validos, digo son obligatorios
-->
yo puedo poner un mensaje que diga los campos son obligatorios, pero a lo mejor
-->
alguien dice no no no, hay que ser mas
-->
amigables con el usuario y hay que decir, el campo email y el campo
-->
es obligatorio, si me explico ya hay una variedad de mensajes
-->
para que no me pongan a mi hacer el mensaje
-->
cambiarlo en que se me ocurrio, para que no hayan muchos
-->
quien creen que deberia tomar la decision de cual mensaje poner
-->
y quien de nuestros compañeros de aqui creen que pueda ser esa persona
-->
que por ahi yo me acuerdo que Arturo era como el project manager, si estan de acuerdo
-->
que tiene que ser el, digamos un project manager tal vez, un product owner
-->
por ahi, ahi dice que si
-->
perfecto, entonces que mensajes crees
-->
que puedan ponerse por ahi Sergio
-->
digamos tu ya hablaste con las gerencias ya te dijeron
-->
que mensaje podrias poner, como se te ocurre ahi
-->
como poner
-->
perfecto, algo asi
-->
ok, aqui la idea es mas que nada como que ustedes vayan teniendo como
-->
la idea de, con el rol que tenemos
-->
que cosas van de tu cancha y que
-->
cosas van en la cancha de otras personas, lo que decíamos
-->
ayer en el concepto de los stakeholders, todos los que estamos
-->
involucrados, quienes somos quien, esto que estamos haciendo
-->
ahorita, es su dia a dia me imagino
-->
es lo que ustedes ven en su dia a dia, no se si
-->
mas o menos le atinea a que Sergio hace ese tipo de
-->
validaciones, el trae esa informacion, el trae los requerimientos que hay que hacer
-->
si ahi, por ahi no es, si por ahi
-->
eliot, son los que se ponen a desarrollar, todo eso
-->
no se si vamos en el mismo canal
-->
en cuanto a la practica, y sobretodo si son los roles
-->
adecuados
-->
o alguien tiene un rol diferente
-->
exacto
-->
perfecto, muy bien, basicamente todos son
-->
todos los logos, son project managers, son
-->
desarrolladores
-->
exacto, ah perfecto
-->
bueno entonces con mas razon todos y cada uno cualquiera de ustedes
-->
le puedo preguntar practicamente cualquier cosa y
-->
pues pueden responderlo, sin embargo para que se vea un poquito como
-->
la dinamica, vamos a tomar esos roles, Sergio va a ser nuestro project manager
-->
todos los demas somos del equipo de desarrollo
-->
vamos a alternar roles entre desarrollo y tester
-->
y pues bueno asi es como vamos a estar trabajando
-->
este primer ejercicio que hicimos, asi como practica de rebotar, de bajar requerimientos
-->
y demas, pues son las cosas que ahora entiendo
-->
pues son su dia a dia, ustedes van teniendo ahi como las llamadas
-->
con los involucrados, los usuarios finales, y van haciendo ese
-->
levantamiento de requerimientos que despues se traduce a un
-->
a una metodologia agile, si en donde
-->
hay un tablero levantan las historias de usuario
-->
y van dandole ese seguimiento, entonces listo
-->
no se si por ahi tengan alguna duda, alguna pregunta, todos lograron
-->
acceder al formulario, perfecto
-->
muy bien, entonces ya para terminar esta primer practica
-->
vamos a hacer ya, entrar en materia de lo que es
-->
una prueba unitaria, si, vamos a ver como se ejecuta
-->
la prueba para que nos sirve, retomemos un poquito
-->
y vamos a ver pues como se desarrolla
-->
como se interpreta, basicamente
-->
lo que deciamos ayer, la prueba unitaria
-->
es una prueba que esta del tipo funcional
-->
son pruebas funcionales, una prueba unitaria basicamente lo que
-->
nos permite es hacer una prueba dentro de un modulo
-->
dentro del mi desarrollo, si, que valide la funcionalidad
-->
de dicha funcion, valga la redundancia
-->
dentro del código sabemos, los que nos dedicamos
-->
ya entiendo son todos ustedes, nos dedicamos a la parte del desarrollo
-->
sabemos que hay diferentes
-->
entidades que entran en la programacion
-->
ya sea de la programacion, el paradigma que ocupemos ya sea programacion
-->
funcional, ya sea programacion declarativa, ya sea programacion
-->
por programacion orientada a objetos
-->
no se, el paradigma que tu ocupes, finalmente vas a tener
-->
reglas o entidades que
-->
se relacionan e interactuan con el desarrollo, que tu vas a
-->
poder ejecutar los bloques, entonces en la programacion orientada a objetos
-->
que es el paradigma que aqui tenemos, cortesia de .net
-->
nosotros tenemos una
-->
forma de poder referirnos al código, sabemos
-->
que se pueden hacer clases, que pueden haber interfaces
-->
que pueden haber metodos, que pueden haber objetos
-->
que pueden haber utilidades, que bueno, en general
-->
un todo, todas y cada una de esas entidades
-->
que yo antes les mencione, se pueden probar
-->
y se pueden, no tanto se pueden sino que se deben probar
-->
en un paradigma de test, bueno ahi ya solo el pomodoro, denme nada mas
-->
4 minutitos y ya cerramos el
-->
el siguiente comodoro
-->
basicamente lo que yo trato de decirles es que una prueba funcional, una prueba
-->
unitaria, lo que me permite hacer es
-->
ver con mucho mayor
-->
digamos, con mucho mayor detallo, mucho
-->
mayor aislamiento mejor dicho, el código en unidades
-->
funcionales, en funcionales
-->
unidades unitarias, vamos a decirlo asi, o en bloques
-->
unitarios y poder aislar las piezas o los componentes
-->
y probarlos por separado
-->
con el objetivo de ver como si fuera una caja negra, en la que ayer
-->
platicamos, la caja negra es al cual una entidad
-->
que esta obscura al publico, nadie la puede, nadie
-->
puede ver que hay adentro, pero lo que si sabemos es que tiene entradas y tiene
-->
salidas, eso es lo que nosotros necesitamos en una prueba
-->
unitaria, una prueba unitaria la va a hacer
-->
ahi bueno, quisiera tener un poquito de noción, les
-->
pregunto, ustedes creo que ayer me dicen que no estan tan habituados en hacer
-->
pruebas, como que si las hacen, pero como que no les dan como el seguimiento o algo
-->
así, o estoy mal
-->
ah perfecto, pero ustedes digamos si las han sabido crear o las han podido crear
-->
desde cero, excelente, ah perfecto
-->
ah perfecto
-->
ah listo, ok, bueno pues entonces eso da el panorama
-->
para saber como podemos hacerlo, aqui
-->
yo les voy a mostrar los comandos ahorita que regresemos del descanso
-->
como se crea el proyecto de pruebas, sale, pero ahorita
-->
nada mas como para ya cerrarlo, vamos a hacer, bueno creo
-->
no se si tengan alguna duda de lo que es la prueba unitaria
-->
basicamente si yo tengo, ahorita que hablabamos de mi controlador
-->
por ejemplo del login, si, la prueba unitaria lo que me va a permitir hacer es
-->
probar todos y cada uno de estos metodos
-->
y validar que funcione, una prueba unitaria
-->
basicamente es otro, es un programa, si, es un programa, es una aplicación
-->
es otra clase, si, es otro estilo de programación
-->
que cuando yo la programo, yo la ejecuto
-->
esa prueba lo que va a hacer es encargarse de pasar parámetros
-->
si, a las cajas negras, que en este caso el software es lo que
-->
está ahí adentro es nuestra caja negra, a la prueba unitaria no le importa
-->
como está o que hay de programación en tu blog
-->
a la prueba unitaria lo que le interesa son las entradas y las salidas, nada mas
-->
sale, entonces eso es lo que ahorita vamos a probar y vamos a revisar
-->
en nuestro archivo de pruebas como se está haciendo diferentes
-->
escenarios de prueba, vale, entonces
-->
vamos a tomar el pequeño descanso de 5 minutos
-->
y les parece si a las 11 en punto nos volvemos a ver
-->
y le seguimos con el tema de la prueba
-->
la ejecución excelente, entonces ahorita nos vemos