Learn-json-web-tokens: Prueba de API que usa JWT

Bueno, tengo algunas sugerencias que podrían funcionar:

1. Configure un cliente _test_ en su sistema y codifique un token en las pruebas. Mantenga la autenticación activada.
2. Asegúrese de que la autenticación esté desactivada al ejecutar las pruebas. Supongo que hay diferentes formas de hacerlo. Por ejemplo, en Hapi puede omitir el esquema de autenticación predeterminado, y solo establecer uno, cuando el servidor realmente se ejecuta (pero no cuando se ejecutan pruebas).
3. Realice una simulación de la pila, de modo que solo esté probando unitariamente la lógica del controlador, sin realizar solicitudes a través del sistema. Sin embargo, puede que no sea factible en algunos marcos.

Estoy trabajando en algunos sistemas, donde elegimos (1). Las pruebas se parecen más a las pruebas de integración y no a las pruebas unitarias, porque se ejecutan en la pila. Por otro lado, no existe disparidad entre el entorno de prueba y el de producción.

Puede configurar NODE_ENV=test , al ejecutar las pruebas (fx. -e parámetro en el laboratorio ), si desea determinar el entorno en el código. Sin embargo, debe tener en cuenta que el entorno de prueba y producción no difiere demasiado, de lo contrario, no está realmente probando el entorno de producción.

@ rhewitt22 preferimos el enfoque descrito por @walling
(donde las pruebas se parecen más a las de "integración" en lugar de a las de "unidad")
precisamente por esa razón. Todo lo que es fingida "_fake_" y por lo tanto no se sabe cuando algo "_real_" funciona o no (_so insectos son más likely_).

Hemos heredado (_large_) proyectos en los que la gente _ se olvida_ de actualizar los simulacros cuando cambian de método y, como resultado, las pruebas no reflejan la _realidad_; _ pesadilla para depurar _!

Siempre pregúntese: "_ (¿Por qué) ¿necesitamos para burlarse de esta _?"

Si se está burlando de algo porque está fuera de su control, por ejemplo, un servicio de terceros o un dispositivo de red,
que tiene sentido. Pero si te estás burlando de tu propia pila, debes considerar que podrías estar complicando demasiado las cosas ...

La pista en su _pregunta_ está en el término " _API _", esto indica que no está probando una "unidad", sino una (API) "_ endpoint _".

Llegue al punto final y si obtiene un 401, ¡sabrá que necesita _authenticate_! (_¡Buenas noticias! ¡Su aplicación funciona como se esperaba! _)

Aquí hay un _ ejemplo funcional _ de una prueba que hace _ exactamente lo que necesita _:
https://github.com/dwyl/hapi-auth-jwt2/blob/f17bac65d40b2a9154da84390b874cae4e1de192/test/test.js#L119 -L135

Entonces recomendaría leer:

• Cuándo simularse: https://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html
• Los simulacros no son talones: http://martinfowler.com/articles/mocksArentStubs.html
• Prueba de microservicios: http://martinfowler.com/articles/microservice-testing/
• ¿Cuándo debería burlarme? http://stackoverflow.com/questions/38181/when-should-i-mock

tl; dr

Si su _ código propio_ es demasiado complejo y siente la _necesidad_ de burlarse de él, _primero simplifique su código _ !!

Además, escribimos nuestro complemento hapi-auth-jwt2 para que otros puedan confiar en nuestras pruebas. Y lanzó un ejemplo _linear escalable_ respaldado por Redis: https://github.com/dwyl/hapi-auth-jwt2-example para que la gente pueda copiar y pegar (_tested_) código. :guiño:

_Sólo nos burlamos cuando nuestras pruebas "_se sienten demasiado lentas _"; de lo contrario, _siempre_ ejercitamos tanto de la pila como _posible_ en cada paso de prueba (mientras que limitamos las dependencias solo a lo _esencial_).

Si un elemento de la funcionalidad de su aplicación requiere autenticación, ¿por qué no lo usa como una _oportunidad_ para _ ejercitar_ sus métodos de autenticación / verificación? En última instancia, saber qué tan _performante_ es su autenticación será _ bueno_ para su aplicación porque la autenticación / verificación es uno de los mayores cuellos de botella en su pila. (es decir, cada _ GET / POST / PUT / DELETE _request_ tiene que pasar por autenticación / verificación, por lo que no debería tomar más de un par de milisegundos ... ¡más que eso y su aplicación _no escalará_!)

Recuerde : No asuma nada y decida cómo tiene sentido probar su aplicación. Si hubiera una "forma correcta" de hacer las pruebas, todas las universidades la estarían enseñando ... no la hay. La "mejor manera" es el enfoque "_pragmático_"; haga lo que tenga sentido para _su_ proyecto.

Espero que ayude. Si no es así, háganos saber dónde está atrapado. : +1:

¡Gracias a los dos! Esto es muy útil. Según su sugerencia, creo que esta configuración se presta a las pruebas de integración; definitivamente quiero saber si estas piezas funcionan juntas.

Solo estoy usando oAuth como mi método de autenticación (sin nombre de usuario / contraseña). Estoy interesado en aprender más sobre cómo crear un cliente de prueba. Sé que no quiero pasar por todo el flujo de oAuth, pero como sugirió codificar un token que pueda usar en mis pruebas. ¿Podría recomendarme algún recurso que pueda ayudarme a comprender la creación de un cliente de prueba?

Si ayuda, mi proyecto actual usa SailsJS v11.0. Tengo un archivo de prueba de arranque que inicia mi servidor y crea / llena una base de datos en memoria con accesorios. ¿Podría ser ese un lugar apropiado para crear un cliente de prueba?

Gracias de nuevo. Es maravilloso encontrar personas tan dispuestas a compartir sus conocimientos.

@ rhewitt22 , bueno, en mi caso, el cliente de prueba fue tan simple como crear un token JWT que no caduca firmado con la carga útil correcta y la clave secreta. Quizás eso ayude.

En OAuth, creo que depende del flujo de autenticación. Tal vez incluso pueda crear el token de acceso final con ciertos permisos y que no caduque, por lo que no tiene que pasar por el flujo cada vez.

Tenga cuidado con las preocupaciones de seguridad sobre la codificación rígida de un token que no caduca en sus pruebas, si ese token también otorga muchos permisos en el sistema de producción. Entonces, un atacante potencial solo necesitaría este token para obtener acceso. Es posible que desee alguna forma de otorgar acceso a ciertos clientes y, al ejecutar las pruebas, puede otorgar acceso a su cliente de prueba o token. Espero que todo tenga sentido.

@walling

¡Gracias por el consejo!

Seguí adelante y creé un usuario falso, omitiendo el flujo de oAuth, en mis pruebas y les concedí el mismo JWT (con vencimiento) que uso en producción. Todas mis pruebas están pasando y soy un campista muy feliz.

:sonríe sonríe Sonríe:

Supongo que mientras trabajo en mi aplicación y miro el servidor de desarrollo, me aseguraré de que la parte de oAuth funcione como se esperaba.