Orador: Guillermo Fernández Resumen: La idea de la charla es mostrar el proceso que hacemos los desarrolladores para seleccionar las herramientas de testing (en particular, unit test y performance) que mejor se adapten para testear un framework.

1. Aprendiendo a testar un
framework desde cero

2. Que es?
● Es un framework para ayudar a desarrollar rest apis con
nodejs usando typescript

3. Componentes
Controllers
Componentes para desarrollar los servicios rest.
En express serían los handlers.
Middlewares:
Componentes para ejecutar actividades antes y
después de la ejecución de los controllers

4. Decoradores
● @Post
● @Get
● @Put
● @Delete
● @JsonController
● @Body
● @Authorize
● @MiddlewareBefore
● @MiddlewareAfter
● @Param

5. Creando el servidor
Se realiza en dos etapas:
1. Inicialización de la metadata
a. Se utilizan los s decoradores.
b. Se almacena toda la metadata en el
GLOBAL de node.
2. Creación del servidor de node
a. Se utiliza las funcionalidades de
node

6. Flujo de ejecución (1)
1. Llega el request.
2. Se obtiene la url y el method del request.
3. Se busca un match sobre la metadata.
a. Si no hay match retorna 404.
4. Se parsea el body en caso de venir en el
request.
5. Se ejecuta la action del controller que hizo
match.
6. Se retorna la respuesta.

7. Flujo de ejecución (2)
Controller ActionMiddleware
Middleware
Middleware
Middleware
Middleware
Middleware
HTTP
Request
hay match ?

8. Middlewares
- Es algo que ejecuta antes o después de cada action

9. Documentación

10. Kiwi cli
Tool para facilitar la creación de código.

11. Porque hicimos testing ?
● Unit test
○ Necesitábamos ir probando parte del framework a medida que se
desarrollaba.
○ Cada vez que publicamos el framework necesitamos saber que lo que
estaba funcionando siga asi.
● Performance test
○ Lo hicimos en dos etapas.
○ Etapa 1: tratamos de mejorar los tiempos contra sí mismo.
○ Etapa 2: tomamos un framework similar (express) y comparamos tiempos
de respuesta.

12. Unit test
Analizamos diferentes alternativas para node.
1. mocha https://mochajs.org/
2. tape https://github.com/substack/tape
3. Jest https://jestjs.io/
En nuestro caso nos quedamos con mocha.

13. Cómo ejecutamos nuestros tests
1. Cada vez que publicamos el paquete
necesitamos que se ejecuten los
test.
2. En caso de que todos esten bien se
publica el paquete.
3. En caso contrario no se publica.
Para esto utilizamos un paquete que se
llama gulp donde automatizamos el
proceso de publish
https://gulpjs.com/

14. Kiwi-cli
1. Cuando creamos un controller por defecto el cli nos va a
crear una carpeta con el controller.ts y un
controller.spec.ts
2. Con esto lo que logramos es crear un test inicial donde
el desarrollador va a poder testear su controller.

15. Performance test (1)
1. Empezamos a hacer test y medir los tiempos de respuesta.
2. Hicimos mejoras en el framework tratando de mejorar esos
tiempos.
3. Se generaron muchos controllers para tener una gran
cantidad de rutas.
4. Los tiempos se mejoraron ya que el problema estaba en el
ruteo.
Para estos test usamos el paquete de npm loadtest.

16. Performance test (2)
1. Seleccionamos un framework del mercado que ya sabemos que
anda bien, es muy usado y tiene una gran comunidad.
2. Implementamos los mismos servicios en ambos frameworks
3. Le hicimos los mismos test para ver cómo responden.
ambos.
Para estos test usamos el paquete de npm loadtest.

17. Links
● https://github.com/ollita7/kiwi
● https://github.com/ollita7/kiwi-cli
● https://www.npmjs.com/package/kiwi-server
● https://www.npmjs.com/package/kiwi-server-cli
● https://www.typescriptlang.org/docs/handbook/decorators.html
● https://nodejs.org/api/http.html
● https://www.npmjs.com/package/loadtest
● https://artillery.io/docs/getting-started/

18. Links de testing
● https://mochajs.org/
● https://www.npmjs.com/package/mocha-typescript#async-tests-befor
e-and-after-actions
● https://github.com/howardabrams/node-mocks-http
● https://gulpjs.com/
● https://www.npmjs.com/package/loadtest
● https://jestjs.io/
● https://github.com/substack/tape