Esto es una charla un poco, un poco extraña porque más que charla va a ser mitad charla,
mitad taller, vale, es un poco, para aquí es un poco cómo empezar, para dónde empezar
y por qué, por qué empezar, no, adquirir test, vale, cuánto de aquí sabéis lo que
es un test y qué es el desarrollo de test, vale, cuánto de aquí sabéis lo que es, por
lo menos, cuánto de aquí escribiste, vale, vale, bastante gente, eso a lo mejor a muchos
os voy a contar cosas que ya sabéis, vale, lo que podemos hacer si queréis es, dar una
primera parte, que será, espero que sea una, una media hora, donde voy a explicar un poco
de fundamentos de testing y lo que yo creo que es importante de los fundamentos del
test y que son los test y porque son importantes, esto es una charla de introducción, vale,
y luego vamos a seguir a hacer una pequeña cata, la más sencilla que hay para trabajar
con TDD y para aprender a empezar test, vale, lo que quiero, el objetivo de esta charla
es que cuando mañana o la semana que viene o cuando os pongáis a trabajar en vuestro
curro, sentáis la imperiosa necesidad de escribir un test, lo que no lo hagáis ya
y los que lo estés haciendo, sentáis la necesidad de saber si estoy escribiendo bien un test
o si el scope de mi test es el correcto o que estoy haciendo bien mal con los test,
vale, bueno, para los que no me conozcáis hoy, si veis en algún momento dado, si estáis
aburriendo, vale, a mitad de la charla veis que, cuando miramos la cata veis que es más,
como somos pocos, vale, veis que es bastante sencilla y todos sabéis un poco, tu explorar
la problemática, me lo decís, si la podemos ir complicando, puedes hacer cosas más complejas,
vale, bueno, para los que no me conozcáis, soy Jorge Joparroso, soy Jorge, Fripper
83 para mucha gente, trabajo en Karumi, soy al de unis desper, no quiero decir nada, solamente
que dedico a trabajar con Androids más tiempo que con cualquier otra tecnología, en teoría
sé mucho de Androids, lo justo, ese es mi correo donde lo podéis escribir lo que queráis,
enviaros, no sé, vuestros candidatos a los globos de peor, lo que queráis, vale, pues
enviaréis el correo, vale, ese es mi Twitter donde escribo de programación, de programación,
de fútbol, vale, y comiendo bastantes fotos de comer, pues una pasión que se ve claramente
tengo, vale, y otro es mi Google Plus que no entro, pero bueno, hay mucha comunidad de
Androids y siempre queda bonito ponerlo, pero bueno, me quedaba un hueco para que fueran
tres, vale, eso es de trabajo, vale, eso es un poco de produce playmen aquí, no, trabajo
en Karumi, vale, Karumi es una pesa de desarrollo sólido que llamamos, vale, somos un estudio
de desarrollo, que lo que hacemos es, es tanto de desarrollo para terceros, vale, con su
teoría al uso, vale, como formaciones, vale, vamos a dar charlas a gente, pero esas formaciones
suelen ser bastante específicas con los equipos o bootstrapping, vamos y trabajamos
con los equipos Kodo con Kodo y estamos trabajando con ellos a diarios, recibiendo sus problemas
como si fuéramos un miembro más del equipo, vale, es un poco lo que hacemos, y esa filosofía
es un poco la de, que es Karumi, vale, que es el camino ordinario de las cosas habladas
en una forma sencilla, vale, tenemos que realizar software que sea sencillo, que sea fácil
entender, que sea legible, vale, que sea sólido, que no se rompa, que este cuento por test,
vale, igual con nuestros, con nuestros clientes, tenemos que ser directos, ser amigos suyos,
ser sencillos, entender sus problemas, cero bullshit, no mentirles, ser honestos, vale,
es un poco nuestra filosofía, somos un equipo muy pequeño, vale, y queremos ser pequeños
a propósito, vale, porque nos interesa que dar un trabajo de calidad y de cercanía,
vale, es un poco lo que es Karumi, el testing es una cosa que, que nació en el, en los
años, en el año 76, vale, por este hombre, por, bueno, por lo menos es la primera referencia
que yo encuentro, de a Game for Meyers, que era la primera persona que empieza a hablar
de testing, vale, tanto testing manual, tanto testing manual como testing, como testing automáticos,
vale, y es la primera persona que intenta decir a los ingenieros que tienen que escribir
test, que tienen que hacer que sus programas se rompan, vale, entonces él tiene un par
de, un par de libros, no me quedo los títulos, vale, pero están, están los equipostos, tiene
un, tiene un par de, tiene un par de libros sobre, sobre testing bastante interesantes,
vale, donde habla, estamos hablando del 76, donde habla de una parte muy primogenia, primigenia
de lo que son los test, vale, y tiene una fase en uno de esos libros que es muy interesante
que dice ésta, ¿no?, que es, el test tiene un proceso de, de, de, de intentar, para intentar
encontrar errores, vale, esta aplicación tiene muchos, esta definición tiene muchas
implicaciones, implica que esto es un proceso de test subtivo hasta sádico, vale, entonces
por eso mucha gente no lo quiere usar, vale, una de las primeras barreras que, que los
encontramos cuando vamos a hacer test somos los otros mismos, vale, a los otros mismos
a veces nos molesta demostrar que nuestro código falla, vale, son los primeros que decimos
la para que voy a probar si ya sé que funciona, vale, y a ver si se da cuenta de que no, que
no funciona, que está roto, vale, y eres tu culpable y le hecha la culpa a los test,
le hecha la culpa al framework, le hecha la culpa que vino antes, o le hecha la culpa
a la, a la, a la pieza de hardware, vale, y a veces la culpa, muchas veces la, a veces
la culpa es tuya.
Así que somos nuestro primer enemigo a la hora de escribir test, y entonces a veces
nos incudamos en que es que mi jefe es que, es que el tiempo que, es que el, el, el so
queso o el trabajo que, vale, para no hacer test, vale, pero bueno, hay que intentar
hacer test, vale, porque escribir test, vale, esta es la primera pregunta que es la más
importante de las que vamos a resolver hoy, vale, porque vamos a escribir un test, porque
voy a invertir tiempo de mi, de mi día a día en el trabajo en escribir test, y es más,
como le voy a decir a mi jefe, vale, o como voy a convencer a alguien de que tengo que
escribir test, vale.
Mucha gente me habla, que tiene empresas de consultoría como la mía, que si yo escribí
test, y yo digo, claro que escribo test, y me dice, ¿y cómo es lo facturas al cliente?
Le digo, yo no le facturo los test al cliente, porque los que, el test no es una cosa para
el cliente, es una cosa para mí, vale, es una cosa que me hace, que yo tenga la seguridad
del que, del que el software funcione, vale, y me hace a mí que yo tenga la, la, la sapiencia
de que he podido dormir por las noches y levantarme sabiendo que ese código ha funcionado, o que
si me piden un cambio rápido no va a cascar, vale.
La primera cosa es vuestra responsabilidad, ¿vale? Imaginaros un panadero, ¿vale?, que
no probara el pan, ¿vale?, que hiciera pan y no lo probara, y que cuando tú fueras
a comprar una barra de pan, ¿vale?, supiera a puta mierda, ¿vale? Claramente no comparías
pan a ese panadero, ¿vale?, ni, o el pan está duro, o sabe mal, o no tiene agua, o de repente
yo qué sé, te pones malo por comer ese pan. Claramente no comparías pan, es su responsabilidad
hacer bien pan. Vuestra responsabilidad es hacer software, y el software no debería fallar.
Yo no espero que el software falle, por lo cual vuestra responsabilidad es hacer software
que funcione. La forma más sencilla que tenéis de hacer
software que funcione es probándolo, claramente. Si no probáis, ¿vale?, igual que un cocinero,
si veis Masterchef, siempre le dicen, ¿habéis probado el plato?, ¿vale?, si veis Masterchef,
es la primera pregunta que les hacen, ¿habéis probado el plato? Y los tíos, no, pues sabe
a puta mierda, y los tíos, a lo mejor no tienen que haber probado, pues esto es lo mismo,
¿has probado tu software? No. Entonces, ¿cómo sabes qué funciona? No, yo los quito y, ¿vale?,
de probarlo, de vuestra responsabilidad como ingenieros, hacer eso. ¿Vale? La segunda
es la, no se puede hacer un de factor, ¿vale?, sin hacer, sin hacer un test. No se puede
cambiar código, sin haber antes hecho un test, porque si yo no tengo ninguna red de seguridad,
si no tengo ninguna forma de comprobar que el código funcionaba como funcionaba antes,
no puedo decir que sea un test, ¿vale?, perdón, no puedo decir que sea un re-factor, ¿vale?,
si no tengo algo que me diga que está funcionando como funcionaba antes, ¿quién me dice que
no he roto algo?, ¿quién me asegura que ese cambio que yo he hecho en mi software para
que sea más legible, es función igual, ¿vale?, recordad que un re-factor, mal usamos la palabra
re-factor, le llamamos re-factor a muchas cosas, un re-factor no es nada mágico, cambiar
código para que funcione de la misma forma que funcionaba antes, desde el punto de vista
de fuera, ¿vale?, el observador externo de algo lo ve igual, ¿vale?, entonces eso implica
que no deben cambiar los contratos, no deben cambiar las cosas que se ponen hacia afuera,
simplemente un re-factor hacia adentro y para que funcione igual, tengo que tener test, ¿vale?,
¿por qué tengo que describir test, ¿vale?, porque los test forman una documentación
viva de vuestra aplicación, es una herramienta de diseño, ¿vale?, es una cosa que es, digamos,
bastante moderna, ¿vale?, tendrá, yo creo que el TDM de 2008, creo 2006, no recuerdo
bien la fecha, por ahí, ¿no?, 2000 algo, ¿no?, y es una herramienta para poder diseñar,
¿vale?, ¿por qué?, porque ahora lo veremos cuando hagamos la Cata, cuando tú escribes
test puedes utilizar los test para hacer test exploratorios, ¿tú no sabes cómo va a funcionar
algo, ¿vale?, ¿tú no sabes cómo va a funcionar algo?, ¿no te imaginas cómo va a ser su API
o cómo va a ser ese código?, y a través de los test, ¿vale?, ¿vas a ir formando
las cosas, porque lo que vas a hacer va a ser, voy a escribir un test que va a definir
cómo quiero que se comporte, ¿vale?, el contrato que quiero que tengas a clase o ese módulo
o esa unidad, ¿vale?, o esa API o esa lo que estoy programando, defino ese contrato, ¿vale?,
y no me importa la implementación. Entonces, al ir escribiendo el test, el test me va
ir dando la implementación. Eso es parte de conocer los principios 1, conocer los principios
de test, ¿vale?, que queríamos alguno y conocer los principios sólidos, ¿vale?, conocer
algunos principios, ¿vale? Hay una falacia maravillosa del TDD, a lo que iba ahora, justamente
que la gente que hace el TDD dice una falacia maravillosa que es la... Eso es, la arquitectura
emerge. Claramente, lo que puede emerger también es la mierda, ¿vale? Entonces, hacer TDD no
te implica que el código que hagas vaya a estar mejor o peor, ¿vale? Yo siempre es
una herramienta que utilizo mucho para que la gente apeta programar. Te parece buenísima
aprender a programar porque te va a obligar a hacer algunas cosas que son buenas para
el desarrollo, que es exponer dependencia, te va a obligar a exponer dependencias, te
va a obligar a intentar dar soluciones concretas a problemas, te va a dar... Te va a obligar
a pensar en los casos de error, ¿vale?, en los casos que no son... Que son corner, ¿vale?,
se hace bien TDD. Claramente, eso no quiere decir que hagas bien una arquitectura, que
tu código sea bueno. Lo que sí que te va a ofrecer... Yo no soy defensor del TDD, ¿vale?
Yo no hago TDD, ni me gusta hacer TDD y siempre lo critico como voy. ¿Vale? Pero es una herramienta
que a veces uso para hacer algunas cosas. Yo estoy haciendo, por ejemplo, una API o estoy
definiendo un framework, a veces lo uso mucho. ¿Vale? Porque a veces no sé qué aspecto va
a tener en mi código. Pero sí que es verdad que si tú ya tienes esa red, ¿vale?, tú ya
has hecho esos TDS a la verdad de hacer TDD aplicado en refactor sobre ese código que
no está bien, porque no está aplicando patrones o porque tiene algunos fallos va a ser mucho
más sencillo que si no tienes esos TDS, ¿vale? Entonces, claramente te va a ayudar
siempre. Siempre es una herramienta que te puede ayudar, pero claramente no demuestras
qué vas a hacer esto. Uno de los grandes problemas que hay a la hora de que con gente
que hace TDD y con gente que se mete mucho del mundo crackman es que acaban haciendo
sobre ingeniería, ¿vale?, porque el scope de sus TDS, ¿vale?, lo que ellos entienden
como una unidad de testing, una unidad a testear, es muy pequeña. Entonces, al tener una unidad
muy pequeña testeable, necesitan moquear los colaboradores. Esto es un poco, para los
que no se pede testing es un poco jarto, pero luego volveremos sobre ello, ¿vale? Necesitan
moquear los colaboradores. Entonces, al final se acaba convirtiendo en un antipatrón,
porque acaban usando antipatrones y acaban usando patrones donde no deben y acaban sobre
ingenierizando, ¿vale? Hacer un interfaz que su auto tiene una implementación o yo qué
sé, haciendo decoradores sobre los ejemplos que no deben, simplemente porque el scope
del test está mal o sacando, exponiendo visibilidades que no deberían estar hacia afuera, ¿vale?
Siempre, bueno, nuestro no lo posto aquí, pero siempre el diseño de, el diseño de
objetos de vuestra aplicación debe imperar siempre sobre los tests y no los tests imperar
sobre el diseño de tu aplicación, ¿vale? Y esa vez hay gente que en el TDD lo confunde,
¿vale? Pero claramente es una herramienta para diseñar y es dinero, ¿vale? El testing
es dinero, salva dinero, ¿vale? O sea, si alguien, cuando tú te tienes que vender,
voy a escribir test a un Tenlit o a un tipo de producto o alguien, lo que realmente tienes
que vender es que escribiéndote es, voy a salvar dinero, ¿vale? Voy a salvar dinero
¿por qué? Por parte de las cosas que hemos visto antes. Uno, porque ya tenemos los bugs,
porque yo mismo estoy testando que la aplicación funciona, ¿vale? Estoy haciendo una labor
justamente nada más por amarla, una labor sádica de ver que eso funciona, ¿vale? Por
lo cual, eso me va a hacer que detenga menos bugs y que las cosas no se rompan, ¿vale?
Eso es, todas aquellas cosas que son importantes para mi negocio, ¿vale? No todo tiene que
estar cubierto de test, no hay que tener un 100% coverage, pero aquellas cosas que son
importantes de mi negocio, sí que tiene sentido que estén bien cubiertas de test, eso por
un lado. Dos, porque nos va a permitir ir más rápido, ¿vale? Porque vamos a poder programar
con más seguridad, no va a ser, no voy a tocar y voy a hacer así, esto lo abre roto,
lo abre roto, que ha pasado aquí, tengo una red de seguridad que me va a permitir hacer
eso, y una red de seguridad que va a permitir aplicar un refactor para cambiar algún código
que me haga falta, ¿vale? Y tercero, porque recordar, esa es una fase que dice muy buena
Martin Fowler, que es que el mal código afecta a tus costumers, ¿vale? O sea que una aplicación
falle afecta a la gente que la consume, ¿vale? Yo siempre pongo el ejemplo, siempre pongo
el ejemplo de CityMap, ¿vale? De pelón de BiciMap, las bicicletas de Madrid, ¿vale?
Que salió y que ellos estaban pancapornos y todo estaba destruido, ahí no había
tem nada, pero puedo poner un ejemplo más sencillo, yo no sé cuál será la cobertura
de test de Google Music, ¿vale? No Google Music, no, de ¿cómo es el servicio que salió
ayer? De Apple, ¿no? Yo sé cuál será la cobertura de test de Apple Music, pero me
parece que el test de abre la aplicación y veo que los strings están puestos no estaba,
¿vale? Y abrir una aplicación donde no funciona los strings o no funcione el botón de login
como pasaba ayer, eso implica que una buena cobertura de test sobre lo que es importante
para tu aplicación, que es lo que es key, que es que el usuario pueda entrar a la aplicación,
está bastante mal, ¿vale? Entonces, claramente es como es Apple y hay muchos fanboys, no
va a pasar nada, pero si en vez de ser Apple es Flipper Music, es mi aplicación de música,
el tío que abre esa aplicación y le da el botón y no funcione o vea y no vea ni los
textos, va a decir, este tío, esto es una castaña, a este tío no le doyó 5 euros al
mes ni por la somo y la voy a cerrar, ¿vale? Entonces, pensad en eso, ¿vale? Pensad que
en hacer testing, aunque sea testing manual, ¿vale? Que sería el último test que queríamos
ver afecta a vuestros usuarios, ¿vale? Estos son aproximadamente porque esto está sacado
de un, esto está sacado de un, de un esto de, de un libro de, de Martin Fouble, ¿vale?
Ahora hay más, ¿vale? Pues eso son aproximadamente todos los tipos de test que hay, ¿vale? Si
os fijáis, hay herramientas, clasicos de testing, varias herramientas de seguridad,
hay y testing manual, está de creguera gina, hay testing automático que está en esta
esquina y hay testing automático y manual, ¿vale? Ahora vamos con lo que nos más, lo
que más nos va a interesar va a ser los test automáticos, ¿vale? Va a ser los test automáticos
porque son aquellos que no necesitan de nadie, ¿vale? Y ahorita vamos a tener una persona
haciendo una recresión, ¿vale? Antiguamente era muy común en el software, bueno, a día
de hoy sigue siendo muy común en el software seguir haciendo test manuales, seguir tirando
un equipo de personas que prueba las cosas, cada vez cuando las casuísticas de lo que
hay que probar crecen, eso ya es jodido, ¿vale? ¿Qué pasa? Que muchos de esos equipos de
testing manuales se han convertido en test funcionales, gente que escribe test que comprueba
como si fuera un usuario hacerlo, ¿vale? Porque cada vez lo que tú no quieres hacer
es estar todo el día, hago login, me voy aquí, doy aquí el usuario, se ve bien, hago
no sé qué, hago no sé cuánto, no hay que hacer eso. Si tú eres una persona que es
una persona un poco viva, dices, joder, a lo mejor hay algo que le hace por mí y hace
esto mismo que hago yo de lo primero que te programas es muevo el ratón al 28-28, clico,
ve a la izquierda, clico, mío si está esto, clico y eso se convirtieron en algunos framework
de testing funcional, ¿vale? Los testing funcionales, los testing notarios, van a ser
los que más nos interese, ¿vale? Pero que se parezca, hay un montón de testing y siga
viendo un montón de testings y algunos orientado más a testing de diseño, como puede ser por
ejemplo los test exploratorios, incluso test que están muy graciosos, como por ejemplo
el otro día me enseñaron un nuevo tipo de test, ¿qué es lo que, cómo se llaman ahí,
no me acuerdo, creo que lo tengo apuntado, que estuve leyendo el artículo lo tengo apuntado.
Los test de propiedad, ¿vale? Los propietaris test que prueban con una batería, valores
random, generan un montón de valores dentro de un rango, ¿vale? Muy grandes para probar
muchas casoísticas, ¿vale? Que eso puede ser por ejemplo interesante, pues para cosas
de vida o para cosas así, ¿vale? O yo que sé, ahora hay una movida que se usa mucho,
que son si procesos, ¿vale? Que lo que hacen es, tú tienes una batería de test, ¿vale?
Y lo que hacen es cogen el código fuente que hay que está testeando ese código y cambian
los switch, ¿vale? O cambian id o cambian force, cambian condiciones de tu código para
ver si los tests se rompen. Si los tests no se rompen, quiere decir que tus tests son una
puta mierda, porque no están comprobando lo que deberían hacer, ¿vale? Si yo cambio
código fuente al contrario y los tests no se rompen, ahí huele algo mal, ¿vale? Pero
hay muchas cosas, ¿vale? Hay muchos tipos de test, no solamente los típicos que hablamos,
que suelen ser estos, que suelen ser test de funcionales, que son test de UI, desde integración
o test unitarios, ¿vale? Que son los que nos vamos a centrar, porque eso es una charla
de introducción a testing, ¿vale? Bueno, eso es lo que se llama la pirámide y el testing,
¿no, eh? Cuantes de aquí conocí la pirámide del testing, todo el mundo, porque esto es
lo que siempre nos cuentan en todos los libros y todos los sitios de la pirámide del testing,
¿vale? Esto alguien, que fue a Martin Fowler, se le ocurrió hacer este dibujito y poner
abajo diciendo que cuando hagamos test, debemos tener un montón de unit tests, menos test
de integración y poquitos test funcionales. ¿Por qué, decía él en aquel momento, decía
¿por qué? Porque esos test unitarios son muy rápidos y los puedo pasar muchas veces,
¿vale? No tienen dependencia de nada. Los test de integración, como a lo mejor tengo
que hacer integraciones de capas, van a ser bastante más lentos si no me interesan, ¿vale?
Y los test funcionales son súper lentos, porque tengo que hacer un test en tu en, que tengo
que ir a un allá, esperar que se llame la API, yo sé que son más frágiles, dependen
de la conexión, dependen del usub, de que el bot del animación haya funcionado, ¿vale?
Además, esos test de aquí abajo suelen ser menos frágiles, si están bien hechos y los
test de arriba son bastante frágiles. ¿Qué pasa que esto, dependiendo de lo que estéis
desarrollando o cómo estéis desarrollando, cambia bastante, ¿vale? No es una pirámide
así, ¿vale? Es la forma o gustos queráis tener. Claramente sí que nos va a interesar
tener test unitarios, ¿vale? Para que van a ser rápidos y van a ser fáciles de escribir.
Pero, por ejemplo, si estás haciendo el diseño de una API, hay test de integración, ¿vale?
Tienes que cruzan todas las capas que te dan mucho valor, desde que llega una request
hasta que se genera una response, ¿vale? Esos test te dan muchísimo valor. Y a lo mejor
a ti te interesa más tener muchos test de esos, aunque estén repitiendo funcionalidades
y estén repitiendo código que tener muchos unit tests, ¿vale? Entonces, aquí siempre
hay una discusión un poco de sobre la base, ¿vale? Además, hay dos charlas que siempre
pongo, que me encantan, que son integration test RSCAM, una charla de Raysenberger, donde
dice que los test de integración son una puta mierda y que no hay que usarlo nunca,
porque todo test de integración se puede hacer con un test unitario, ¿vale? Y creando
test de contrato. O otra charla que es buenísima que es unit test is a waste of time, que viene
a decir lo contrario. Quiere decir, por favor, dejar de escribir de un test unitario minúsculos
que hace que tu software se rompa, ¿vale? Entonces, depende de tu software tenéis que
pensarlo, ¿vale? Está preparando Pedro una charla para el CodeMotion de este año, ¿vale?
de cómo aplicamos en Karumi los test para las aplicaciones de Android, ¿vale? ¿Qué
sentido le damos a cada scope cuando hacemos un test unitario, cuando hacemos un test de
integración y cuando hacemos un test funcional, ¿vale? Porque a veces los test en tu end te
dan mucho valor, ¿vale? Te van a dar mucho valor y van a ser necesarios, pero hay que
saber hacer lo que ocita medida. Lo que claramente no es normal, es lo que ha ocurrido, lo que
ha ocurrido mucho desde el software clásico, que es la pirámide invertida, que es tener
muchos test de UI y ninguno unitario. Los test de aceptación son aquellos que están
hechos desde el punto de vista del usuario, ¿vale? Son aquellos test que hemos dicho que
lo que comprueban es que tú estás clicando en el botón correcto, entonces es como ir
con este botón, veo que ocurre esto y con lo sé que veo que la respuesta es correcta,
¿vale? Esos son los test funcionales, ¿vale? Esos test suelen ser similares, o sea, según
se definen, estos test nacen en el año 2000 con Kenbeck, ¿vale? Y según se definen,
según lo definen, tienen que ser similares al lenguaje natural, ¿vale? Esto a día de
hoy en algunos lenguajes a través de los DSL es fácil hacerlo, ¿vale? Y se quedan
cosas como, por ejemplo, como cálabas, donde a través de un lenguaje natural puedo escribir
los test, ¿vale? Son unos test muy cercanos a los requisitos del usuario, ¿vale? Y permiten
hacer una cosa que está totalmente fuera de aquí, que es el VDD, ¿vale? Pero a veces
cuando él se refiere al lenguaje natural, se refiere que tiene que ser cercano a lo
que el usuario va a hacer, ¿vale? Que tiene que ser cercano a clicar un botón, a ver que
esto sabe por la pantalla, a que sale esta animación, ¿vale? Esto va a hacer que sean
bastante frágiles, ¿vale? Va a hacer que, porque si alguno de esos flujos cambia, se
van a romper mis test. Si mi pantalla de profile cambia, todo mi test relacionado con la pantalla
de profile va a romperse, ¿vale? Y están bastante cercanos a los frameworks, ¿vale?
Esto quiere decir que es muy difícil escribir test funcionales sin usar un framework para
escribir test, ¿vale? Es muy difícil hacerlo a mano, ¿vale? Entonces al final se ve que
usa algún framework. ¿Vale? Como esta charla anterior es de Android, yo se he dejado aquí
tres de Android que son como los más conocidos, ¿vale? Robotium, Appium y Expreso. ¿Vale?
Robotium es como Selenium, Selenium para web, Robotium es para Android, Appium, ¿vale?
Que es como multipataforma y Expreso, que es lo que ha dado Google, que bueno, que tengo
mismasis, ni menos con Expreso. Calabasi es un lenguaje genérico, pues entonces te permite
hacer un montón de implementaciones por debajo. Entonces, con cucumber, lo que hacen es montan
calabas, montan cucumber y ya está. Eso está muy bien, se va a hacer VDD, ¿vale? Si tienes
una persona que defina tus requisitos, que defina los quitos funcionales y que se espera
a usted de aceptación, que se espera de la aplicación, pues está muy chulo. Si no,
yo a nivel personal no los uso, no me voy a ese nivel de acción tan alto, porque no me
aporta nada. Yo lo que he visto es que no temían de funcionar bien, ¿vale? Pero bueno,
si se consiga hacer que funcionen bien, va genial. Pero, por ejemplo, los deseles, los
deseles para escribirte en escala funcionan muy bien y son muy cercanos al lenguaje natural
también. Entonces, es un poco... No lo he usado, ¿vale? Pero si alguien se va a poner
con ello, pues a lo mejor es una solución válida, ¿vale? Lo que es importante es que
si él te define, él te define, los aceptan criterias, aquellas cosas que son válidas para
a tus tés, tú estás guay, porque tú cubres de tés solamente aquellas partes y ya está,
¿vale? Té de interacción, ¿vale? Té de interacción son aquellos que comportan cómodos
módulos se relacionan entre ellos, te sean cómodos módulos colaboran y se relacionan
entre ellos, ¿vale? Esto va a ir bastante ligado con las siguientes likes que vamos
a ver, ¿vale? Que son los tés unitarios. Y me voy a esperar a eso para explicaros más
de interacción, ¿vale? Tés unitarios. Esto, hay un artículo de Martin Fowler otra vez,
¿vale? Que empieza hablando de esto. Empieza hablando que hay 24 definiciones diferentes
de unit test, ¿vale? Yo no sé si se las habrá contado él, ¿vale? Yo no me para contarlas,
¿vale? Pero sí que es verdad que yo conozco 2 o 3, la clásica, la de la escuela de Londres
de Mancuso, que yo lo que entiendes es más o menos la misma y la de comportamiento.
Hay varias escuelas de testing y también de TDD, ¿vale? Pero de cómo enfocar el testing.
Claramente lo más importante aquí, ¿vale? En la carrera la universidad hizo mucho daño
a la hora de explicar el unit test, porque explicaban la versión clásica, aquella de
unit test, donde decía que unit test test sea una clase. No, un unit test no test sea
una clase, test sea una unidad, ¿vale? Test sea algo que es unitario, que es una unidad,
es a lo mejor un sistema con 4 o 5 clases puede ser considerado como una sola unidad,
¿vale? Entonces no tenéis que hacer un test por cada una de las clases o que a veces una
clase pueda tener en su propio test, ¿vale? Lo que sigo si interesa es que tenga una unidad,
¿vale? Porque aquí lo que te va a interesar es testear dos cosas. Uno, estados, ¿vale?
Los estados de esa unidad, si yo hago algo en que estado está, que estado se encuentra
y dos, cómo trabaja con los colaboradores, ¿vale? Un colaborador de un sistema, bueno,
un colaborador de una clase es aquel con que mi clase habla, ¿vale? Una clase puede
ser, puede estar, puede estar sola, puede estar solo a los estados o puede hablar con alguien,
¿vale? Si yo tengo una clase que se encarga de hacer alguna cosa, pues te trago una entrada
y una salida, ¿vale? Lo mejor, es una clase que habla con un frango o lo cual habla con
alguna cosa, ¿vale? Entonces eso es lo que lo va a interesar y testear esa unidad, ¿vale?
A veces lo que es lo grande y lindamente difícil del testing, ¿vale? Una cosa que hacemos mal
con el testing es que intentamos creer que yo me voy a poner, ¿vale? Hoy me voy a sentar
y voy a saber escribir test, ¿vale? Hemos tardado en aprender a programar, yo por lo
menos está teniendo a programar cinco, seis años a programar bien, siete años a mojar
a programar bien, ¿vale? Y queremos aprender a escribir test bien en una semana o en dos
días. Claramente eso no va a ocurrir, ¿vale? Porque el ámbito del testing es tan grande
como cualquier otro ámbito del desarrollo, como puede ser el back end o como puede ser
el front end o como puede ser las cavidad, los sistemas, no sé qué, ¿vale? Entonces
por eso hay que dedicarle tiempo y la experiencia de sumbrado y leer también, es importante
y ver qué aplica que no aplica. Es mal las reglas, ¿vale? Las reglas que aplican a veces
en el desarrollo normal no aplican en el testing. Por ejemplo, típica regla que aplica el
desarrollo normal, el don repeat yourself, ¿vale? Si vas a hacer algo dos veces extra lo afuera,
no aplica en el testing. A veces en el testing para que sea más legible te interesa repetir
cosas, ¿vale? Para poner un ejemplo. Entonces lo primero que hay que hacer cuando se hace
cuando se ha estado en equipo es definir qué es un test unitario, ¿vale? Definir qué es
un test unitario. A partir de ahí vamos a definir qué es un test unitario y qué es un test de
integración, ¿vale? ¿Por qué? Porque las unidades son las que nos van a decir cuáles
son las integraciones. Para mí, por ejemplo, todo el código que ocurra dentro de una capa,
¿vale? De mi software, puede ser un test unitario y todo aquel código que sea entre dos capas
de mi software es un test de integración. Por ejemplo, podría ser una definición válida,
¿vale? Lo que sí que es importante y todo el mundo está de acuerdo con eso, los unites,
es que deben estar isolated, deben estar desacoplados de sus colaboradores, ¿vale? Esto es importante.
Un test unitario nunca debe depender de sus colaboradores y tienes que saber quién es
su, ¿vale? Importante, tenéis que saber qué es un colaborador, ¿vale? Hay gente que extrae
propiedades de una clase como un colaborador para poder moquearla. Claramente ahí lo que está
ocurriendo es que el scope de tu test está mal, ¿vale? Y tener un scope pequeñito, ¿vale? No hagáis
un dirictés de toda vuestra aplicación, ¿vale? Porque al final no tienen ningún sentido, ¿vale?
Ya no es unitario, ¿vale? Ya es otra cosa, ¿vale? Y los unites no son super, ¿vale? Lo que decíamos
antes. Hay mucha gente que defiende que toda la vida tiene que ser unites, no hay que hacer
una cosa que no sea unites y es mentira, ¿vale? Hay veces, sí, lo puedes hacer, sí, como toda la
vida con tiempo, ¿eh? Con tiempo y saliva todo entra, ¿vale? Entonces, pero hay que tener,
hay que tener cuidado, ¿sabes? Entonces, hay que usar otras herramientas que tenemos,
tenemos la integración, tenemos la integración y se puede utilizar por otras cosas, ¿vale?
Y bueno, voy a repetir lo mismo, un test no tiene porque ser una clase, el scope puede ser mayor.
Esos son cinco reglas que se escribieron para definir un unit test bien, que son
cicoleras que tienen que cumplir un unit test, ¿vale? El mismo técnico que crearon es el de
First, ¿vale? Pues para que os acordéis bien o que sea solid os podéis acordar de First, ¿vale?
Voy a especular un poco a uno. Los test tienen que ser rápidos, eso quiere decir que tienen que
agarrar poco, ¿vale? Se tienen que ejecutar rápido. Así que, olvidaros de, pues no sé,
leer de la red, en un unit test no debería de leer de la red, un unit test no debería de tener un
slip, no debería tener combinación de hilos, no debería de tener un gel, ¿vale? esas cosas que
no, que hacen que no sean rápidos, ¿vale? Y hay una discusión súper guapísima que podéis
poder buscar entre DHH y Reisberger, de cuánto tiene que, y Ken Beck, de cuánto es el tiempo que
tiene que dudar una materia de test para que sea la polla y es como, eh, y nos sacara, ¿vale?
Tienen que estar isolates, vamos a repetirlo de antes, ¿vale? Hay lados de su entorno para que
puedas moquear, aunque el Bob dice una frase valiosa, que es como un test unitario, tiene que, tengo
que poder ser capaz de controlar el mundo en el cual se ejecuta, o casi es como, guap, flipante, ¿vale?
Un test tiene que ser repetible, ¿vale? Eso quiere decir que sí, que lo tiene que ser
dependiente de ningún otro test y que lo puedo lanzar, ¿vale?, en cualquier entorno, en cualquier
máquina, que va a funcionar igual, ¿vale? Tiene que ser self verifying, ¿vale? Eso es que no tiene
que mirar en ningún sitio para hacer nada, ¿vale? Tiene que escribir un log y ver que en el log
es que es funcionando, alguna cosa así, y tiene que ser timely, ¿vale? La gente confunde fast
com timely, por eso hay muchos actores que ponen transparente, ponen también transparente, ¿vale?
Timely quiere decir que se tienen que escribir rápido, ¿vale?, que tiene que ser fácil de leer y
fácil de escribir, ¿vale?, y fácil de comprender, que yo vea y que sepa que está pasando, ¿vale?
Con que vamos a trabajar cuando hagamos un test, recordad que una de las cosas que tienen es que
tienen que estar isolates, tienen que estar desacoplados de las cosas. Vamos a trabajar con
una cosa que se llama test doubles, ¿vale?, o sea, con la de los crackdummies, ¿vale?, de aquellas
cosas que tiran y se... de los dobles, de los extras de la película, de los dobles que son
muñequitos, pues esto es el mismo concepto, ¿vale? Vamos a cambiar a nuestras casas de verdad por
doubles, ¿vale?, por clases ficticias. Hay cinco tipos, ¿vale?, los steps, que lo que son, son
respuestas enlatadas, ¿vale?, cuando yo te digo cuál es tu idea y tú me vas a decir tres siempre,
¿vale?, los mocs, que lo que vamos a hacer es comprobar qué es que ha pasado por ahí el código,
comprobar expectaciones, por ejemplo, si yo tengo un colaborador que es enviar correo, ¿vale?,
si fuera un step, yo que hago es enviar el correo, guardo... en enviar correo, digamos que...
no, un ejemplo, enviar correo, cuando digo ha llegado el correo, le pregunto y cojo el valor, ¿vale?,
los mocs es cuando yo llamo, enviar correo, marco que ha pasado por ahí, ¿vale?, y le pregunto,
ha pasado por enviar correo y me dice sí, ¿vale?, esto sería un moco, ¿vale?, es ver las expectaciones
si se ha llamado, si se ha llamado con los argumentos que yo quiero, si ha funcionado el método como
yo quería. Los space es hacer lo imparecido, guardar información, ¿vale?, los fakes son
objetos, ¿vale?, que son parecidos a los de verdad, ¿vale?, imagínate el típico caso de que tienes
que interactuar con algo del sistema, ¿vale?, algo que tú no puedes moquear porque se escapa a ti,
pues creas el mismo objeto y lo pones, ¿vale?, entonces, por ejemplo, una implementación de
math, ¿vale?, un fake fácil, ¿vale?, imagínalos que yo tengo que ver el tiempo, ¿vale?, tengo que
hacer un get system correct de milis, ¿vale?, y esperarme 50 milisegundos para capturar la
caches, ¿vale?, y no quiero hacer eso, ¿vale?, yo no quiero tener un get 40 milisegundos en mis tests
y un ellipo, un wait en mis tests, lo que hago es cuando pido la clase que me devuelve la clase del
sistema, ¿vale?, que devuelve 40 milisegundos, tengo un fake y lo que hace es que me devuelve uno,
que me devuelve uno, dos, tres o mil clientos y yo les puedo cambiar los valores, ¿vale?, y un dummy
es un objeto que no hace nada, ¿vale?, por ejemplo, imagínalo que yo tengo un sistema analíticas en
mi aplicación, pues cuando se cobre de los tests, en vez de pasarle el sistema analítica de verdad,
le paso uno vacío para que simplemente no crasee o no hagan nada, ¿vale? ¿Cómo escribo un test?, ¿vale?,
cuando escribimos un test, lo más importante, ¿vale?, es seguir estas tres reglas de un test
unitario, que me tiene que haber un given que es dado a esto, ¿vale?, para hacer un test, es un test
y yo creo que voy a probar algo, ¿vale?, por ejemplo, creo que voy a probar si un número es par, ¿vale?,
pues el given sería dado un número, entonces, ¿vale?, llamo a la función par y miro si el número es par,
si me ha dado un par el par, ¿vale?, o sea, siempre se ocupan estas tres reglas, hay gente que lo llama
AAAA, que es... nunca me acuerdo, es feísimo, no sé qué es, ha sido la última y lo otro es... nunca me acuerdo, ¿verdad?
¿Me acuerdo cómo era? A... A... Analys... Arrange... no sé qué, assert, ¿no? Bueno, no es igual,
mira, hacer lo mismo, pero comparar las mafias para que sea AA, ¿vale? Given when then, given when then
es una regla maravillosa, además si en vuestros test lo hacéis por bloquecitos, ¿vale?, given when then, ¿vale?,
lo veréis, los que seáis de... que ten... Oye, Ticé o de César que tenéis regions, pero eso incluso una
region, ¿vale?, los que se dejaban, o sea, están guarros de ponerme comentarios, comentarios, given, porque eso, ya con los
inter se puede ver, ¿no? Vale, y lo importante, cuando empecéis a hacer el test, esto fue un tweet que nos puso una vez
Ray Berger a Pedro y a mí, que es cuando tiene mucha sed, cualquier agua, ¿vale?, cualquier agua te puede
mantener vivo, ¿vale?, que estés trabajando con una... con una base de código en vuestra casa, ¿vale?,
cuando se está bajando con la base de código en vuestra empresa, ¿vale?, y ya está, ¿vale?, y no empecéis a decir,
venga, voy a cubrir todo el test, no, empezar a escribir un test, ¿vale?, para ver cómo funcionan, otro test,
dos daréis cuenta que a veces vuestro código no está preparado para escribir un test unitario,
entonces ahí hacéis un test de aceptación, aunque no sea la mejor solución, ¿vale?, o sea, lo importante es ir teniendo
el test, ¿vale?, tenéis cuidado porque un mal test a veces es peor que no tener nada, ¿vale?, pero que eso, cuando tengáis sed,
cualquier agua podrida puede ser buena, ¿vale?, o sea, si vais a hacer un refactor cubrir de test, la parte que vais a refatorizar,
aunque sea con test de aceptación, ¿vale?, a lo mejor es muy interesante, porque por lo menos vais a tener la tranquilidad
de que no vais a romper vuestro software, ¿vale?, y luego cuando os queráis el software nuevo, cubrís con test unitario
y veáis el software nuevo, si podéis, y os corregáis y sostén de aceptación que ya le den sentido, ¿vale?
Muy bien, Fía, para que cuando suba la charla la veáis, ¿vale?, muchas cosas de esta charla las he cogido,
estaba muy bien estructurada de las tres a dos primeras, la he hecho al verde de Kini y el Elegant Unit Testing de Palo Guardiola,
que son de charlas muy interesantes, ¿vale?, y los están las dos en vídeo, las podéis ver las dos, ¿vale?, y son muy, muy interesantes
sobre fundamentos de test y de programación, y luego, bueno, libros y charlas muy interesantes.
Ahora lo que vamos a hacer, ¿vale?, alguna pregunta hasta aquí, ¿vale?, vamos a hacer una cata.
Yo trabajo con Fuente 24 siempre. No, te trabajamos fuente 24. Esa fuente que habéis visto la que yo trabajo en mi día a día, en la Fuente 22.
Aquí tener la fuente grande, ¿vale?, como mínimo 20, me lo agradeceréis, por dos cosas, bueno, por tres cosas.
Uno, vuestra vista, no tenéis que estar así, una fuente 12, que no tenéis ninguna necesidad de tener una fuente 12.
La siguiente, porque es más fácil enseñar código a alguien y hacer y hacer programing, es como, oye, mira este código,
y no tiene que estar así como a Chinao, ¿vale?, y te hacerlo porque vuestros métodos van a ser bastante más pequeños.
Pero está demostraísimo, ¿vale?, vuestros métodos, como ya no caben en la pantalla, van a ser bastante pequeños.
¿Cuántas de aquí sabéis lo que es una cata de programación? Bueno, los que no lo sepáis.
Una cata de programación es, viene de las catas de estado de yudo, ¿vale?, y es hacer un ejercicio muy sencillo,
repetirlo muchas veces, ¿vale?, para asimilar conceptos. Es programación, se hace un poco lo mismo, ¿vale?,
se cogen más o menos sencillos, desastran y se pueden aplicar cosas.
Se suele utilizar TDD, ¿vale?, para los que no sepáis, TDD es una herramienta de diseño de software,
donde primero se escriben los tests, se ve que el código falla, ¿vale?, después de eso,
se hace la implementación para que esos tests pasen, ¿vale?, se funciona,
luego se aplica un refactor, ¿vale?, para dar a cosas que están bien y se va a hacer así, se va iterando, ¿vale?,
te es que es rojo, verde, refactor, rojo, verde, refactor, ¿vale?
Entonces, hay una cata que es la cata más sencilla, ¿cuánto de aquí conociste el FITBAD?
¿Vale? Pues bueno, para los que no lo buscan os caeis, os lo había contado un poco la cata que es,
pero es la cata más sencilla de VTESTI, ¿vale?
Lo que viene a decir es, en una clase, en una clase de colegios de unos niños,
se hizo, se hizo un ejercicio, ¿vale?, que es un juego muy divertido, que es contar, ¿vale?,
entonces, donde cada vez que hay un número que es 3 o divisible entre 3, se dice FITBAD,
y cuando hay un número que es 5 o divisible entre 5, se dice BAD, ¿vale?,
si hay un número que es divisible entre 3 y 5, ¿vale?, se dice FITBAD, ¿vale?,
pero no hay que esperar a contar y es 1, 2, FIT, 3, no, he hecho mal, 1, 2, FIT, 4, BAD, ¿vale?,
y os hubiera perdido el juego, ¿vale?, a la primera, además, entonces, lo que vamos a hacer es,
os fijáis, es un problema sencillo, es bastante sencillo, ¿vale?, pero está bastante bien para aprender a hacer TDD,
entonces, vamos a aplicar a hacer TDD con esto, ¿vale?,
y como hemos dicho, primero deberíamos escribir el primer test, ¿vale?,
el primer test que se me ocurre escribir, ¿vale?, es saber si un número es 3, ¿vale?,
entonces, vamos a poner aquí notaciones, si soy capaz, hola, no me troles, ¿vale?
Bueno, esto es Java, ¿vale?, los que no tengáis Java, para los que no tengáis Java, funciona igual, todo, ¿vale?,
a lo mejor hay algunas cosas como, por ejemplo, estas notaciones para JTUNY4 y tal, pero las reglas que vamos a aplicar
son iguales en todos los lenguajes, ¿vale?,
una cosa importante es el nombre que le damos a los test, ¿vale?,
perdón, el nombre que le damos a los test, ¿vale?, y a los métodos, ¿vale?,
una cosa que tenemos que hacer es que el nombre de un método, ¿vale?, sea que el nombre de un método sea muy descriptivo
y diga lo que hace nuestro método, nuestro test, ¿vale?,
entonces, antiguamente, si os vais a cocinar Java antiguo, los test empezaban por test,
perdón, simplemente porque era una habitación de framework que no lo ponía, ¿vale?,
yo voy a usar esto, las clases test y los métodos empezando por soul, ahora veréis por qué, ¿vale?,
pero bueno, mancuso de moda que las clases se dejaban de llamar test y fueran feedbacks soul
y los métodos no tuvieran soul en la palabra, ¿vale?,
pero que así era bastante más legible, pero bueno, pero que todos los test son soul, ¿vale?,
entonces, si yo escribir un test, por ejemplo, crees que lo que tengo que hacer es
debería decirme, debería devolverme fit cuando recibo un 3, ¿no?,
entonces, ¿qué tengo que hacer en STS? Comprobar, bueno, aquí tengo una clase que es la que yo voy a comprobar, ¿vale?,
que es feedback, ¿vale?, comprobar que si yo a feedback, ¿vale?, a process o como le dame, ¿vale?,
¿qué, un feedback, ¿vale?, ¿vale?, si yo a feedback, lo llamo, bueno.
Sí, ahí nos hace, no me acuerdo de quién es, pero hay una fase que dice, hay una fase maravillosa
que es el software, el desarrollo software, solo hay de cosas complicadas,
que es la generación de Caches y el naming, y es claramente, y yo ahí tengo un día bastante fíjago con los nombres, ¿vale?,
entonces, bueno, si yo hago esto, ¿vale?, bueno, esto no funciona la misma, ¿vale?,
y ahí me invito, ¿vale?, ¿vale?, no, aquí va la expectation, ¿vale?
¿Vale?
Da igual, o sea, en teoría da igual, pero cuando te dé el error, cuando vaya a salir el error, vas allá al revés, ¿vale?,
entonces, no lo mismo leer, yo esperaba recibir un, yo esperaba recibir, aquí en este caso,
imagínate que este de tu malud es un cinco, ¿vale?, yo esperaba recibir un cinco y me ha llegado un fizz, ¿vale?
Bueno, y incluso este no sería primer test que tendríamos que haber hecho, ¿vale?,
vamos a hacer, vamos a hacer primer test, ¿vale?, ¿vale?
¿Vale?
Ahora se explico esto, bueno, vamos a ver aquí, mejor así, y ahora lo hacemos, ¿vale?
Si os fijáis, se cumple lo que decíamos antes, tenemos un given, que es el fizzbuzz que hemos creado,
tenemos un when, que es cuando ocurra esto, cuando se llame con ocho, y tenemos una ser equals ocho, ¿vale?
Entonces, ahora lo que vamos a hacer es calcular esto aquí, ¿vale?, quedamos en el método, ¿vale?,
y en este caso, lo que hacemos es...
Si os fijáis, ¿vale?, si esto lo estuviera programando, bueno, esto vamos a dar un nombre mejor, ¿vale?
Si eso estuvimos haciendo el problema, ¿vale?, no estuvimos usando técnica de TDD, eso está mal, ¿verdad?,
¿verdad?, ¿vale?, si esto estuvieramos haciendo el...
El problema a mucha gente se pondría programar aquí todo, y empezaría a pesar casuísticas, no sé qué,
el TDD de una cosa que en teoría te da, es que tú solamente resuelves los problemas para las casuísticas de entrada, ¿vale?,
entonces no empiezas a hacer extractiones prematuras, ni empiezas a resolver problemas que no tienes y tal, ¿vale?,
entonces a veces ocurre bastante, ahí da poco para eso, ¿vale?
Entonces, si yo ocurrera esto, debería fallar, yo tendría un error, ¿vale?, claramente el TDD falla,
como lo ves aquí en esta parte enana, ¿vale?, aquí me dice que el TDD está fallando, ¿vale?,
¿por qué? porque no hacemos nada.
Entonces, ahora, lo que se suele hacer en TDD, ¿vale?, yo tengo esta carta ya escrita, ¿vale?,
no la subí al red para la subiré esta noche, ¿vale?, lo que se suele hacer en...
o esta noche, mejor más bien mañana, lo que se suele hacer es...
hacerse el comid con red, ¿vale?, fallando, ¿vale?, y luego lo haces con verde, ¿vale?
estas cosas, por favor, no les hagáis en vuestro día a día de desarrollo, ¿vale?
las catas son un ejercicio de aprendizaje
y hacer eso de red, green, refactor, red, green, refactor, va a hablar, refactor, va a hablar,
te va a ayudar a que cuando quieras volver sobre esa cata
para ver cómo lo has visto con problemas, para ver cómo evolucionaste,
el historial de tu repositorio, ¿vale?, te va a dar una visión bastante buena
de lo que estás haciendo, ¿vale?
Bueno, ahora falla, ahora sí tengo que hacer esto, ¿vale?
y esto debería dar un verdecito, muy bien.
¿Vale? Siguiente cosa que el problema que tenemos, ¿vale?, que hemos dicho, que es...
joder, tío.
Vale, ahora sí, ¿no?
Este gallo me lo puedo sacar.
Vale, no se importe, no se importe ser verbosos, ¿vale?, ser verbosos en ese nombre.
Si ese nombre de ese test tiene un nombre así largo, no se importe.
Incluso, o sea, ¿verdadis que decía que hay reglas que aplican para el código
y no aplican para los tests?
Por ejemplo, un código, un método, con un ANT, ¿vale?
Si yo tengo un método que es...
Calculate el número en send to network and store in the persistence.
Eso, claramente, ese método está mal, porque tiene más de una responsabilidad
y hace más de una cosa.
Ese ANT es un code, me dice, aquí esto huele mal, chicos.
Esto está bastante mal, ¿vale?
Si le pongo un test, si yo le pongo un test, por ejemplo,
debo de volver feed cuando recibo un 3 y pasamos el que nos cuento
y pasamos el que nos llevó otro,
ahí sí tiene sentido porque es lo que está haciendo el test, ¿vale?
No te me dice, bueno, no sé, ahora que sea algún DSL que directamente pongas el X-Rig...
No, ojalá.
No, en escala eso sí que hay, pero en Java no.
También lo hay, sí.
También.
Es que hacer DSL en Java es un poco mierda, ¿vale?
Es un poco caca.
Vale, y ahora aquí, si tenemos otra cosita, ¿vale?
Por una cosa que es importante, esto es bastante cultura,
bastante discusión sobre esto a veces, ¿vale?
Esto ya es mi opinión personal.
Yo cuando tengo valores en los test que no son concretos, ¿vale?
Que me da igual, qué valor sea, solo hacer esto, ¿vale?
¿Agua así?
¿Vale?
No, esto no.
¿Agua así?
¿Vale?
Y aquí, por ejemplo, llamo any...
Any value, ¿vale?
Y aquí igual, ¿vale?
¿Otra vez el M, coño, o es el C?
¿Vale?
Entonces, con esto, va a quedar bastante guay,
entonces puedo utilizar eso en muchos sitios.
Si hay algo en este test, ¿vale?
Que es un 3, yo aquí voy a hacer lo mismo.
A ver.
Los prengos de test, ¿no te da también alguno así por ahora?
¿Lan para clases mulas o...?
Te da unos, pero no todos.
Al final no son sus autoridades.
Sí que sí que te da unos valores, por de cierto, pero...
Al final es casi mejor esto, ¿sabes?
Sí, ya.
Vale, y aquí hacemos lo mismo, feedback, calculate.
Vale, y en este caso sí que queremos que sea para 3, ¿vale?
Cogemos el valor, retumbalium.
¿Vale?
Y hacemos el ACQS, ¿vale?
Y aquí lo mismo.
No, aquí es un 3, comillas, comillas.
Vale, si veis ahora, en este caso no me interesa tener ese 3, ¿vale?
No me interesa por ese 3, porque no lo quiero omitir.
Creo que el test, diga, es un 3, y lo que es el test,
sabe que eso está así porque tiene que ser un 3, ¿vale?
Pero no tiene que ser, eso está mal, ¿no?
Perdón, perdón, perdón, perdón, eso está mal, claramente.
Sí, sí, sí, eso está mal, ¿vale?
¿Qué? ¿Estaba hablando metagribía?
Entonces, dejo de pensar.
Eso pasa una cosa a la vez.
Si os fijáis, ¿vale? Ese feed, ¿vale?
Y eso no lo pongo como constantes, porque no me interesa.
Me interesa que esté claro y el que leía el test dice,
vale, esto tiene que ser feed por huevos,
o esto tiene que ser un 3 por huevos,
o esto tiene que ser null por huevos,
o esto tiene que ser la multiplicación de número neperiano,
yo que sé, ¿vale?
Entonces, si yo la yo con las ETs, me voy a fallar, muy bien.
Muchas gracias, ¿vale?
Ya le voy aquí a calculate y lo que yo hago es, ¿vale?
Pero aquí sí que me va a interesar de hacer esto, ¿vale?
Porque aquí estoy dentro del código y las reglas
hemos dicho que no son las mismas, ¿vale?
Y con este código pues ya pasaría los tests, ¿vale?
Entonces, claramente el de 5 lo voy a copiar
porque si no va a estar aquí esta mañana.
Por intentar no copiar test,
porque al final es cuando se lia la cosa, ¿vale?
Copiar y pegar una 5, este sería un 5
y este sería bus, ¿vale?
Y lo mismo, ¿vale?
Me voy a quedar 5 y hago el caso.
Bueno, no voy a estar haciendo rojo verde, rojo verde
pues si no, vale, pero...
Esto es un poco bonito, ¿vale?
Y ya tenemos el primer caso, que es el de para 3 y para 5, ¿vale?
Ahora nos faltan los dos casos, que es el múltiplo de 3 y múltiplo de 5, ¿vale?
Igual, voy a copiar este aquí, ¿vale?
Un múltiplo de 3, puede ser por ejemplo 9, ¿vale?
Y de volver 5 también, ¿vale?
Y hace lo mismo para el múltiplo de 5.
Perfecto, lo ves, por eso me voy a copiar y pegarlo.
Vale, luego Pedro le da Correview y dice, ¿por qué pone aquí Paz cuando devuelve, no sé qué, y tú?
Interesante, ¿vale?
Y aquí un ejemplo, podría, si fuera, si yo fuera idiota, ¿vale?
Si yo fuera bastante idiota, haría, pondría 15, ¿vale?
Y me fallaría el test, ¿vale?
Interesante esto, ¿no?
Vale, pero bueno, vamos por el 25, ¿eh?
Esto es este, bueno, ahora lo hacemos de facto.
Esto debería fallar, claramente, y ahora lo hacemos al calculate, ¿vale?
Si el número es...
Aquí, esto lo he visto muchas veces y la gente hace esto, ¿vale?
No.
Lo he visto en muchas catas de...
En muchas veces que la gente hace esta cata, hace esto, ¿vale?
Y es como...
Amigos, te daros cuenta de una cosa muy interesante, ¿vale?
Que es que el segundo caso cumple el primero.
Entonces, esta parte de aquí no es necesaria ya, ¿eh?
¿Vale?
Eso también es otro problema del PDE, ¿vale?
Hay que pensar si los nuevos casos cumple los anteriores.
Vale.
Vale.
Con este cambio, si yo borrar los test, debería algo en pasar.
Vale.
Ahora falta los dos, ¿vale?
El divad.
Antes de hacer el de los dos, ¿vale?
Vale, vamos a hacer un refacto.
Vamos a hacer varios refactos.
Primero, esto de aquí no me gusta, ¿vale?
Esto debería ser un...
Any...
Of three.
Vale, y este debería ser any multiple of four.
Vale.
Vale.
Entonces, nos vamos aquí.
Entonces, ahora voy a hacer un pequeño refacto de aquí también, ¿vale?
Como me va a hacer falta...
Bueno, no, vamos a hacerlo así, ¿vale?
Hemos definido, ¿vale?, que vamos a definir pit-bust aquí.
Que hemos dicho que si un número es divisible entre... entre tres y cinco, ¿vale?
Vale.
Vale.
Que llegue a ese múltiplo de tres y cinco.
Llama el acostante, muy bien.
Esto le damos el quince, que es múltiplo de tres y cinco.
Vale.
Y aquí le vuelvo...
Esto debe ser el fit-bust, ¿vale?
Y aquí vamos a hacer un calculate.
Vamos a hacerlo a los plan...
Cutron, ¿vale?
Para que os deis cuenta de una cosa.
Y hacerlo peor algún, tío.
Vale.
Esto le suele el problema cada vez, ¿no?
No, porque esto va aquí, ¿vale?
Vale.
Y si yo paso a los tres...
Pasa a los tres.
¡Uy!
Todo en verde.
Vale.
Ahora voy a hacer mi primer refactor, ¿vale?
Que esté...
Un poco más pero esto, ¿no?
Entonces, como ya tenemos toda la carta hecha,
lo vas a ir dejando el código un poquito a poquito,
poquito a poquito mejor.
Primero refactor que haría yo, ¿vale?
Claramente esto lo estoy usando en dos sitios,
entonces a lo mejor tiene sentido que esté aquí en un método...
Is, es, es...
Mejor, ¿vale?
Is fit.
¡Oh!
Y me dice...
¡Esta polla, esto!
Me dice el IntelJ.
He encontrado una duplicación de eso.
¿Quieres que la cambie?
¡Claro!
Esto lo tenéis en la IDC, ¿eh?
Ya tenemos la coda que es igual.
Ya, ¿eh?
Pero no quiere, no quiere que use.
No quiere que use ese...
Bueno, eh...
Ah, pero...
Vale, y aquí Isbath.
¿Vale?
Hacemos lo mismo.
Me dice que sí, claramente si quiero.
¿Vale?
Y ya funciona mejor y está un poquito más limpio.
¿Vale?
Lo siguiente que hagamos,
si os fijáis aquí yo he dejado esto un poco a posta
para que nos demos cuenta de que lo único que hace
esto es...
Si es eso, suma.
Si no, suma.
¿Vale?
Entonces yo puedo tener aquí algo así como...
¿Vale?
Eso es.
¿Vale?
Yo aquí acumulo y hago esto igual a comillas, comillas.
¿Vale?
Y esto ya no me sigue para nada.
Entonces aquí hago el acumulado.
¿Vale?
Por favor, poner brackets.
¿Vale?
Vale, y aquí pongo el acumulado también.
¿Esto está bien?
¿Vale?
Y esto debería funcionar igual, ¿no?
Bueno, no.
De igual.
Ah, vale.
De igual.
Yo digo que funciona igual.
Entonces hago un refactor y fallan todos los 3.
¿Vale?
Vale.
Ahora veis por qué es mola tener test, ¿vale?
O sea, yo esto lo hubiera hecho tranquilamente.
O sea, yo esto lo hubiera hecho tranquilamente en un código de producción antes del cambio
del método y dice, ya está.
Y se te lo voy a poner el puto retur.
¿Cuántas veces habéis devuelto nul de un método así por que sí?
¿Vale?
Vale.
Dejo mit y a la mierda todo.
Vale.
Vale.
Y por ello también.
Vale.
Vale.
Vale.
Vale.
Vale.
Vale.
Vale.
Vale.
Vale.
Vale.
Vale.
Vale.
Vale.
Vale, vale.
Vale.
Vale.
Vale.
Vale.
Vale.
Pero no va a dar cierta ventaja ahora.
Bueno, ahora tenemos una solantada y una sola salida, que a mí me asoplo un poco, pero
mucha gente que les mola tener una solantada y una sola salida.
Esto iba a decir yo algo con respecto a esto.
Otra cosa importante, el desarrollo, si os fijáis que ha pasado aquí, cuando yo he cometido la pata,
ahí había tres o cuatro tíos que ha dicho eh, a este falta no sé qué.
Por eso es importante de vez en cuando hacer técnicas como peer programming o core reviews.
Para mí las core reviews creo que es la cosa más necesaria del desarrollo de software.
Yo creo que ya no podría vivir casi sin core reviews, porque te da mucha tranquilidad
y hace una cosa, sobre todo en equipos que son más de una persona, consiga hacer una cosa que es muy muy chula,
que es que todo el código sea homogéneo.
¿Por qué? Porque como todo el mundo está leyendo el mismo código, todo el mundo uno,
no hace unas oscuras del código porque todo el mundo la tiene que leer,
bueno, todo el mundo, la gente la tiene que leer el código,
entonces el conocimiento no está solo una persona, la gente que la ha leído más o menos a como funciona
y dos el código acaba siendo homogéneo porque...
o programas por imitación de cosas que han visto en otras core reviews o
o, o, o, ¿Oye, mirá esto así?, y al final acaba siendo homogéneo.
¿Vale? Esta va... a mí es una técnica que me ha aparecido el último año, es genial.
¿Vale? Entonces no estoy en las cosas a la tremenda cuando se digan algo, ¿vale?,
No sé, es cabezones, porque hay veces que la razón es varias,
hay veces que la razón puede tener la madura persona,
escuchar lo que dicen, pero a mí me parece una herramienta super buena.
También hay que tomarse la en serio,
hay que no hacer las core reviews por obligación,
sino tomarse la en serio, dedicarle tiempo.
Yo estoy trabajando en core reviews,
por ejemplo, en S.C.M. estamos haciendo core reviews,
y yo me leo todas las core reviews de S.C.M.,
son siete tíos por la mando,
yo me las leo todas, el único que hago es leerme los core reviews.
Si trabajas por core reviews,
y haces core reviews pequeñitas,
por favor, nunca hagáis una core review
que tenga más de 30 ficheros, porque si no,
viene más chete y os corta los brazos, ¿vale?
Como mucho, a ver, 30 ficheros si tenéis 35,
porque tienes S.C.M. y tal, me vale.
Pero siempre muy pequeñitas, porque van a ser más comentarios.
Esto es en Karumi,
en Karumi tiene un tamaño medio de unos 15 ficheros, ¿vale?
Y en S.C.M. tiene 30, y ahí la de 30 y 40 te empiezan a cansar.
Es verdad que a lo mejor de 30 a 40 ficheros,
cinco o seis son de compilación XML,
y otros cinco o seis son ficheros de test, ¿vale?
Que son más fáciles de leer, pero sí, a veces que sé que cansas.
Entonces, lo mejor es muchas veces,
dices, no, pero es que tengo una fiatura,
que es muy grande, pues haces una rama, ¿vale?
Te quedas una subrama y haces core reviews a rama,
y con eso consigues tener el mismo problema, ¿vale?
Seguimos repartilizando, hacer core reviews, amigos.
¿Qué estamos aquí haciendo? ¿Vale?
Estamos repartilizando esta parte.
Si os fijáis, la discusión está bastante guay,
pero podemos darle un poquito más de generalidad.
Si os vais a la cata,
la cata está siempre cuando acaba la base,
empiezan a agregar cosas, como por ejemplo,
si es tres o cinco, haced no sé qué.
Si es en ese momento, haced no sé qué, ¿vale?
Entonces, una solución que podemos dar a esto,
además, hay un movimiento supercragman de la polla,
que es el noif, ¿vale?
No hay que usar ifs, amigos, los ifs.
Ifs are evil, ¿qué dicen, ¿vale?
¿Por qué? Porque contra más caminos,
contra más bifurcaciones y más caminos
tengo un código, la casuística de artes en mayor,
y más fáciles de que metas la puta pata, ¿vale?
Entonces, ellos dicen, no hay que usar if,
pero claramente, las estructuras de selección están ahí, ¿vale?
Me da igual que tú no uses que hagas un if tú a mano,
o que estés usando unas otras datos, el if está ahí, ¿vale?
Así que es verdad que hay que intentar, por favor,
no tener ocho ifas ni dados, esas cosas, ¿vale?
Entonces, vamos a hacer una solución a esto
sin tener que utilizar ifs, ¿vale?
Hacemos con lo bien como era, porque lo hice el otro día, ¿vale?
Entonces, claramente, lo que podríamos hacer es aquí,
cuando hacemos el constructor, ¿vale?
Tener aquí una lista de reglas, ¿vale?
Vamos a tener aquí una lista.
Vale, tenemos una lista de reglas.
A esta lista creamos una regla, ¿vale?
No estamos en los 80, ¿vale?
Los 80 ya se fueron.
Tenemos controles de versiones, ¿eh?
¿Vale? Puedo ver cuando así puso el commit, ¿eh?
Botón derecho, botón derecho blame,
y me dice, ¿qué lo comitéo?
¿Y quién fue? ¿Vale? Y por línea, ¿eh?
¿No, portal? ¿Vale?
Mentira, además, yo tengo un amigo mío que para demostrar
que esto es una mierda, esto fue la polla, ¿eh?
Yo cuando trabajaba en videojuegos,
hacíamos, trabajaba en una mesa de videojuegos, ¿vale?
Y yo tengo un colega mío que para demostrar
que esto no se veía para nada y que era una puta mierda,
lo que fue haciendo era cada vez que habría un fichero, ¿vale?
Se iba al Outdoor y se ponía él, tío.
Bueno, ¿vale? Se ponía él, tío.
¿Vale? Y el cabrón.
Y al cabo de tres meses, me parece, de cuatro meses,
tenía la autoría del 90% del código.
Era soy autor de todo el código, ¿vale?
Y la puta verdad es que la gente tenía a preguntar,
¿cómo está esto? Dice, no sé si yo solo entré a abrir
para tocar una constante.
Era, me partí el culote.
Muy colgado, tío.
Sí, sí, yo tengo, a ver,
esto es porque me he creado un poquito vacío y tal,
y aquí no tengo la cal...
y es que él lide con el que probamos Calaf,
es mi idea de Android y tengo de todo, ¿vale?
Era porque para escribirte es mejor un proyecto Java simple
que con el que esté estudio no se puede.
Entonces, aquí me voy a crear un objeto Rules, ¿vale?
Lo vamos a hacer, vamos a hacer astracto, ¿vale?
Y que tiene que tener un método...
Bueno, malísimo el nombre, ¿eh?
Vale, vale, ni de coña. Procesas ecas. Procesa.
Transforman un número a un string, ¿vale?
Entonces yo tengo que un rule y esto se atrata.
Vale.
Claramente yo tengo que unar el resto de reglas y importe esto.
Vale. Y voy a tener tres reglas.
Vale. Claramente voy a tener un new fifth rule. Vale.
Hay varias formas de hacer esto. Vale.
Voy a tener un problema aquí, pero bueno.
Voy a tener aquí un problema porque aquí me va a hacer falta.
Vale.
Y ésta me sobra.
Vale.
Pues creo que un objeto caja. No voy a poner aquí ancho y alto y luego meterlo a hacer un refactor. Vale.
Pero bueno, ya lo digo. Vale, entonces creamos el traffic rule este. Vale.
Aquí.
Vale, que extienda de rule.
Bueno, hubiera sido otra cosa muy chula también, ¿eh?
Ahora. Vale, implemento los métodos. Vale.
Y ahora aquí me cojo esto. Vale.
Que tengo aquí.
Y me lo llevo aquí.
Te tengo fuera. Te tengo fuera también, ¿no?
Muy bien. Me llevo aquí la pata y no me había dicho nada.
Estas contantes están sin usar. Vale.
Vale.
Y esto devuelve.
¿Por qué pasa de mí?
Ah, no tengo bien con fuera aquí. Vale.
Pues aquí mucha gente pasaría por usar un terenario. Vale.
Creo que se es capaz de tener ese terenario. Sí, ¿no?
Creo que aquí tiene sentido ese terenario. Es más.
Estos paréntesis de los juegos quitar y quedaría hasta más limpio. Vale.
Esto por un lado.
Por otro lado, mira, voy a hacer una cosa. A ver si funciona.
Que es yo puedo venirme aquí, leía su dulce y hago...
Refactor...
Ojet. Vale. Refactor...
Metodojet.
Por expresión.
Ah, no, le voy a hacerlo de aquí entero. Ah, espérate, a lo mejor puedo hacerlo de aquí. A ver.
¿Qué listo quieres?
Sí, señor. Vale. Y esto es el busrule. Vale.
Bueno, esto metodo no se llama así, pero bueno.
Habla con rename. Vale.
¡Buf! ¡Buf! ¡Buf! Me la he creado como el puto culo, nada.
No, no habéis visto nada.
¿Dónde me la he creado?
¡Vaya movida! Esto yo lo he hecho y no que te amenazco. Vale, va de igual.
Bueno, creo que es pesado.
Vale.
Vaya mojón que ha cagado ahí, ¿no?
En el tune value...
Lo hiciste, entonces...
Comidas, comidas.
Eso está de vez.
Este ya queda un poco más feo.
Pero bueno.
Y esto voy a hacer un refactor que debería ser más en singular, ¿vale?
Pues un arrule.
¿Cómo lo ha llamado? Mal bueno.
Vale, esto claramente está mal, porque esto tiene que ir en varios adres.
Bueno, espérate. Bueno, no.
Me voy a hacer el guardro, le voy a hacer así esto. Bueno, sí.
Vale.
Voy a tocar este bojo con este.
Esto ha dado una raíz, ¿no?
Esto es una lista.
¿Por qué? Ah, no, es adiós, el método.
Vale, esto lo voy a sacar aquí. Me gusta.
Vale.
Vale.
Y ahora quitamos todo esto de aquí.
Vale.
Vale.
Y ahora...
¡A lo hombre!
Vale, por eso es una cosa bastante chula.
Cuando tengáis un método que reciba...
Bueno, esa cosa puede ser un string y no la podéis liarparda.
Pero cuando tengáis un método que tenga que recibir un objeto por valor, ¿vale?
Y queréis modificarlo dentro de la clase.
No lo modificáis dentro, porque estáis ocultando la implementación de lo que está ocurriendo.
¿Vale? Nadie sabe que se está modificando.
Entonces, si queréis hacer eso, te volverlo.
Aunque lo modificéis y volvéis en la instancia, devolverlo siempre.
Vale, para que así se sabe que ese objeto se está siendo modificado.
¿Vale? En este caso no lo estoy modificando,
pero si lo modificara dentro, lo devolvería igual.
¿Vale?
Todos valores son por referencia, excepto los tipos básicos y los inmutables.
Vale, por ejemplo, los inmutables son long int, ¿vale?
Todos los tipos básicos y el string.
Por eso todos esos van por valor y por referencia al resto de objetos.
¿Vale? O sea, el string no se pasa por referencia.
Se pasa una referencia, pero como no puedes mudar el contenido del objeto dentro del método, se devuelve por valor.
¿Vale?
¿Vale?
Bueno, y luego hay algunas cosas extrañas, dependiendo del actual,
que por ejemplo, si utilizas un integral.3, no se pasa por la misma referencia siempre,
donde estés en el compilador, pero bueno, esas cosas, fuma de esas.
Sí, los 1024, los 1024, ¿no?
¿Y ahora falla todo?
¿Por qué falla?
Buf, 25, esto está mal.
Tengo mal la del empty, ¿vale?
Si no es Enti, si es Enti, es Enti, ¿vale?
¿Vale? Perfecto.
Entonces aquí tenemos una implementación que no tira de test, ¿vale?
Me voy a quedar aquí porque ya son las 8.30, ¿vale?
Nos hemos quedado siempre en muchas cosas del testing, por ejemplo, mox, cosas así, ¿vale?
Pero bueno, o sea, más o menos esto es como lo más básico del testing para aprender, ¿vale?