Y qué pasa con el salto?
También lo tenemos que probar.
Igual que el nombre.
Vamos a crear un método.
Pero antes con alguno vamos a ampliar el editor, es decir, vamos a ocultar la pestaña Proyecto y dejamos
pantalla completa.
Bien, lo primero, crear.
Bueno, este método siempre tenemos que notar Context para indicar.
Es cierto que es un método que vamos a ejecutar como una tarea.
Entonces texto bajamos.
Voy yo.
Nombre método test, por ejemplo.
sĂłlo cuenta.
Test saldo cuenta bajamos bien y tenemos que crear la instancia de cuenta con los input, con los datos
de ejemplo.
Bueno, podemos utilizar el mismo la cuenta Andrés con el bit decimal, con el saldo del mismo que tenemos
bienpero utilizando intelige podemos hacer lo siguiente Por ejemplo, en vez de escribir cuenta como
tipo dato cierto y la variable cuenta igual.
New cuenta podemos colocar simplemente new cuenta
con Andrés Coma bit decimal el salto New Princess Liman.
Con el string, con el valor élmismo exactamente igual 1000 koma.
Pero bueno, usamos el punto 1 2 3 4 5 exactamente el mismo.
Bien, entonces sobre cuenta el tipo dato la clase.
Entonces me voy a ir a cuenta por acá.
Acá de vejan sobre cuenta sobre esta clase vamos a colocar control alt corta.
Automáticamente se crea el objeto con el tipo.
Se declara no cierto.
Se define la variable cuenta y colocamos cuenta.
Dirigiéramos cuenta.
Perfecto.
Entelequias tenemos.
Bien.
Ahora tengo que probar utilizando acerto y cuáles
hacer y cuales vamos a afirmar un valor esperado.
El mismo vamos a colocar 1000 pero de la literal double como número, no como string 1000.
Punto 1 2, 3, 4 5.
Ese es el nuestro valor esperado y lo vamos a comparar con el valor convertido a un double del big decimal.
Entonces cuenta.
Punto.
Guet, salto, punto.
Y acá buscamos double valeo doble alío.
Entonces lo que hace bueno salto del tipo bit decimal lo convertimos a un tipo double y lo comparamos
con la literal double.
Por eso colocamos 1000 punto uno, dos, tres, cuatro, cinco.
Veamos, es igual.
Si pasa la prueba, está perfecto.
Entonces, con control Schiff F10 ejecutamos.
Acá están ejecutando solamente el método en cuestión, se fijan saldo, cuenta.
No estamos ejecutando 3 nombre cuenta si no esté acá y es porque cuando ejecutamos tenemos el click,
hicimos click dentro el método.
Bueno, de otra forma pasó.
Ahora, si queremos ejecutar la clase completa, bueno, hacemos un clic en cualquier parte, fuera
del método, dentro de la clase.
Por ejemplo acá y lo mismo cheff control F10 y va ejecutar todo.
Toda la clase cuenta test y acá aparece de sĂłlo cuenta test nombre quanta.
Los dos métodos y los dos se fijan tests.
Han pasado dos de dos.
Está todo correcto.
Acá ejecuta según un orden que determinista.
Pero eso lo determina de forma automática, según un criterio propio que maneja el motor de test de
unit del test en Yeung, no a ejecutar en un orden alfabético, ni tampoco el orden en que se definen
los métodos en la clase no completamente determinista.
Y tampoco tiene ninguna importancia para nuestra prueba.
En realidad, lo que estamos acá probando son piezas de código que están completamente separadas.
Independiente no hay ninguna relación una con otra y es un principio bien importante en pro unitaria.
La idea es que en nuestra pieza de código que vamos a probar, no esté relacionado con el resto.
El resto de nuestro código sea completamente independiente y por eso también el orden no es importante.
Claro, podríamos pensar.
Claro.
Yo quiero primero ejecutar un método test que genere algún atributo, que asigne algún valor, algún
atributo, la clase no cierto.
Y después en otro método que se ejecute más adelante, poder utilizar ese dolor.
Es decir, que la clase test maneje un estado en la instancia de nuestra preguntaria.
Y en realidad no es así.
No debiese manejar estados.
Tiene que ser sin estado.
Staines y los métodos unos con otros que estamos probando no tengan nada que ver que no estén relacionados.
Ahora, de toda forma de hecho kaikki se ejecuta un método de la clase test cuenta test.
En realidad es una instancia distinta.
Se crea una instancia distinta de cuenta test para ejecutar este método.
Después, cuando se ejecuta de saldo por debajo en la plataforma de unit en el test engine también se
a crear una instancia distinta a la primera.
Con este método, entonces se crea otra instancia para ejecutar este otro método y es así como funciona
el ciclo de vida.
Por lo tanto cada instancia se distinta.
Si acá asigno un atributo es atributo de la clase, no va a tener un valor.
Cuando se ejecute este método, no va a tener una referencia de que son instancia diferente.
Bueno, después vamos a ver todo lo que es el ciclo de vida.
Lo importante por ahora, saber y tener claro que el orden era lo mismo de otra forma igual después
vamos a ver cómo ordenar los métodos.
Por ejemplo, si queremos organizar y que se vean visualmente ordenada, ya sea utilizando el nombre
método y que ordene de forma alfabética o utilizando la anotación order, también con un número, le
podemos dar un orden.
En fin, hay diferentes métodos y formas.
Continuamos.
Ahora, qué pasa si quiero tener otra prueba?
Una regla de negocio?
Por ejemplo hacer fours?
Vamos a colocar acerte fols.
Bueno, por supuesto que acá espera una condición booleana, una expresión booleana va a comprar algo.
La idea que es algo, devuelve fols.
Por ejemplo, quiero afirmar y me quiero asegurar de que el saldo nunca sea negativo, puede ser cero
si puede ser cero o mayor que cero, pero jamás negativo.
Si esta condición que vamos a escribir es falsa, estaría perfecto, cuenta.
Punto Getz saldo.
Acá lo tenemos bien.
Saldo es del tipo bit decimal.
Es un objeto de referencia.
No es un entero, no es un punto flotante, un doble, un float.
Por lo tanto, no podemos comparar con esto de acá, es decir, que sea mayor que o que sea menor que
en este caso.
Me gustaría comprar con esto, que no se cumpla, que sea falso, que 0 sea mayor que el salto, se
fijan.
Eso es lo que quiero comparar, pero utilizando bit decimal.
Esto no me sirve.
Entonces punto bit decimal lo comparamos con el comparto, comparto ahora este método compar tu devuelve
un entero no cierto que puede ser menor, cero o uno.
Ahora lo vamos a ver.
Lo comparamos con un cero, pero no es un cero numérico, no es un cero del tipo bit decimal.
Entonces claro, podemos crear la instancia new bit decimal y le pasamos el cero en el constructor de
C del tipo String o el tipo entero.
O bien podemos utilizar la constante Big decimal punto cero.
Ahí la tenemos.
Entonces, esta constante cero de la clase bit decimal devuelve un cero bit decimal y lo comparamos.
Entonces, que sea falso, que cero es mayor que el salto.
Entonces acá colocamos menor que cero, es decir, que cero sea mayor que acá.
Esta expresión ahora, por qué esto es compar tú?
El tú puede volver menos uno, cero o uno.
Cuando es negativo menor que uno, significa que el salto es menor que cero.
O dicho de otra forma, que bit décimas cero es mayor que el salto.
Ahí devuelve menos uno.
Entonces, si fuese así.
Es decir, si cero es mayor que el salto perfecto, devuelve menos uno y lo compran con cero cero en
mallorquin menos uno.
Trum va a devolver un truco.
Por lo tanto, acá esperamos un FOLS.
Y va a fallar nuestra prueba, lo que afirma que el salto en negativo es menor que cero y nuestra prueba
no pasa.
Ahora, si el saldo es mayor, entonces va a devolver uno.
Se fijan un número positivo uno.
Si el saldo es mayor que cero, uno es menor que cero.
No, por supuesto que no es mayor que cero.
Entonces, al ser mayor que cero, esta expresión no se cumple y es falsa al ser falsa.
Afirmamos que sea falsa y se cumple la prueba unitaria.
Por lo tanto, el saldo no sería menor que cero, sería mayor que cero.
Y es justamente lo que queremos probar.
Punto, Ikoma.
Bueno, por supuesto, el saldo que lo tenemos como mil puntos y algo vamos a probar, pero vamos a
probar la clase entera.
Hacemos un clic fuera de la clase y control Cheff F10.
Paso la prueba.
Entonces se cumple esta torre y la de negocio primero.
Un valor esperado con el valor real o actual llega una regla que el saldo tiene que ser mayor que cero.
Ahora, qué pasa si colocamos menor acá Menorca?
Ejecutamos?
Falla, falla esta prueba.
Bueno, Akagi Gutié en el método.
En realidad voy a ejecutar fuera del método.
Pero si pasa el nombre nombre cuéntate correcto, es decir, esta prueba que tenemos acá pasa sin ningún
problema, pero falla.
Esta de acá se fija, entonces falla una y pasa una.
Y acá probamos que el saldo no puede ser negativo.
Entonces cuanto negativo?
Bueno, podríamos hacer algún tipo de decepción, algún error en nuestro código.
Bueno, después vamos a ver manejo decepción utilizando pruebas unitarias también como una regla de
negocio, entonces lo vamos a quitar para que esté bien.
De hecho, esto que tenemos acá sería lo mismo.
Voy a copiar, bajamos y pegamos.
Bueno, sería exactamente igual a colocar en vez de menor, con más mayor.
Es decir, que esto sea mayor que cero.
Cuando el salto sea mayor que cero.
Si salto mayor que cero acá es uno, uno es mayor que cero.
Perfecto.
Acá cambiamos en vez de fols.
True es exactamente lo mismo.
Fols.
Pero cambiamos.
Acá damos vuelta la casilla menor y acá sería mayor, ya casi fols.
Y ya casi teatro.
Pero en el fondo estamos peleando exactamente lo mismo con la lógica inversa si esto lo ejecutamos por
acá afuera.
Pasa la prueba.
Bien, a partir de la siguiente clase vamos a ver un poco desarrollo orientado, pruebas unitarias,
es decir, lo que se le conoce como test driven development.
Bueno, orientado a pruebas o desarrollo.
Guiados a pruebas, que es una técnica.
Desarrollo de aplicaciones de software que involucra dos partes.
Primero, escribir primero las pruebas unitarias, no cierto.
Primero escribimos nuestros test y después implementamos el código.
Después, mediante refactorización, implementamos los METHOS.
Entonces, primero nuestras pruebas.
Bueno, primero el método.
Sin nada, sin ningún tipo de código algoritmo.
Lo probamos.
Obviamente va a fallar.
Y después escribimos el código.
Implementamos la lógica negocio, el algoritmo que necesite, el cálculo o lo que sea, lo que tenga
que hacer.
Y después volvemos a probar hasta que afirme el valor y pase la pro.
Y eso es lo que vamos a empezar a hacer crear métodos, probar y después implementar ese método y volver
a probar que nuestro desarrollo siempre esté orientado a pruebas unitarias.
Continuamos en la siguiente clase.