Learn-json-web-tokens: JWT를 사용하는 API 테스트

글쎄, 나는 효과가 있을 수 있는 몇 가지 제안이 있습니다:

1. 시스템에 _test_ 클라이언트를 설정하고 테스트에서 토큰을 하드코딩합니다. 인증을 계속 켜십시오.
2. 테스트를 실행할 때 인증이 꺼져 있는지 확인하십시오. 다양한 방법이 있는 것 같아요. 예를 들어 Hapi 에서는 기본 인증 체계를 생략하고 서버가 실제로 실행될 때 하나만 설정할 수 있습니다(테스트를 실행할 때는 제외).
3. 스택을 조롱하여 시스템을 통해 요청하지 않고 컨트롤러 논리만 단위 테스트할 수 있습니다. 그러나 일부 프레임워크에서는 실현 가능하지 않을 수 있습니다.

저는 (1)을 선택한 일부 시스템에서 작업하고 있습니다. 그런 다음 테스트는 스택을 통해 실행되기 때문에 단위 테스트가 아니라 통합 테스트처럼 보입니다. 반면 테스트 환경과 프로덕션 환경 사이에는 차이가 없습니다.

코드에서 환경을 확인하려는 경우 테스트(fx. -e 매개변수 in lab )를 실행할 때 NODE_ENV=test 설정할 수 있습니다. 그러나 테스트 환경과 프로덕션 환경이 크게 다르지 않다는 점을 알아야 합니다. 그렇지 않으면 실제로 프로덕션 환경을 테스트하는 것이 아닙니다.

@rhewitt22 우리는 @walling이 설명한 접근 방식을 선호합니다.
(여기서 테스트는 "단위" 테스트 대신 "통합"과 더 유사함)
_정확히_ 그런 이유로. 당신이 조롱하는 모든 것은 "_fake_"이므로 "_real_"이 작동하는지 여부를 알 수 없습니다(_그래서 버그가 더 가능성이 높습니다_).

우리는 사람들이 메소드를 변경할 때 모의 업데이트를 _잊어버리고 결과적으로 테스트가 _현실_을 반영하지 않는 (_large_) 프로젝트를 상속받았습니다. _ 디버깅하는 악몽 _!

항상 스스로에게 물어보십시오. "_( 왜 ) 우리 가 이것을 조롱해야 합니까?_"

제3자 서비스나 네트워크 장치와 같이 통제할 수 없기 때문에 조롱하는 경우,
말이 되는군요. 하지만 자신의 _자신의 스택을 _조롱하고 있다면 일이 너무 복잡할 수 있다는 점을 고려해야 합니다...

귀하의 _question_의 단서는 " _API _"라는 용어에 있습니다. 이것은 "단위"가 아니라 (API) "_ endpoint _"를 테스트하고 있음을 나타냅니다.

끝점에 도달하면 401이 표시되면 _인증_해야 합니다! (_좋은 소식! 앱이 예상대로 작동합니다!_)

다음은 _ 당신이 필요로 하는 것을 _ 하는 테스트의 _ 실제적인 예 입니다.
https://github.com/dwyl/hapi-auth-jwt2/blob/f17bac65d40b2a9154da84390b874cae4e1de192/test/test.js#L119 -L135

그렇다면 다음을 읽는 것이 좋습니다.

• 조롱할 때: https://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html
• 모의는 스텁이 아닙니다: http://martinfowler.com/articles/mocksArentStubs.html
• 마이크로서비스 테스팅: http://martinfowler.com/articles/microservice-testing/
• 언제 조롱해야합니까? http://stackoverflow.com/questions/38181/when-should-i-mock

헐 박사

_자신의_ 코드가 너무 복잡하고 그것을 조롱할 _필요_를 느낀다면 _먼저 코드를 단순화 _!!

또한 다른 사람들이 우리의 테스트에 의존할 수 있도록 hapi-auth-jwt2 플러그인 을 작성했습니다. 그리고 _linear 확장 가능_ Redis 지원 예제를 출시했습니다: https://github.com/dwyl/hapi-auth-jwt2-example 그래서 사람들이 코드를 복사하여 붙여넣을 수 있습니다(_tested_)! :눈짓:

_We_는 조롱 할 때 우리의 시험 "너무 느린 _feel _"그렇지 않으면 우리 각 테스트 통과에 _possible_로 스택만큼 _ALWAYS_ 운동 (단지 _essential_에 대한 의존성을 제한하면서).

앱 기능의 요소에 인증이 필요한 경우 인증/확인 방법을 _실행_할 _기회_로 이를 사용하지 않으시겠습니까? 궁극적으로 인증/검증이 스택에서 가장 큰 병목 현상 중 하나이기 때문에 인증이 얼마나 _성능이 좋은__ 알면 앱에 _좋은_ 것입니다! (즉 _모든_ GET/POST/PUT/DELETE _request_는 인증/검증을 거쳐야 하므로 몇 밀리초 이상 걸리지 않아야 합니다... 그 이상은 앱이 _확장되지 않습니다_!)

기억하십시오 : _ 아무것도 가정하지 마십시오_. 애플리케이션을 테스트하는 것이 어떻게 의미가 있는지 스스로 결정하십시오. 테스트를 수행하는 "올바른 방법"이 있다면 모든 대학에서 그것을 가르칠 것입니다. "가장 좋은 방법"은 "_pragmatic_" 접근 방식입니다. _your_ 프로젝트에 의미가 있는 일을 하세요.

도움이 되기를 바랍니다. 그렇지 않은 경우 어디에서 막혔는지 알려주십시오! :+1:

둘 다 감사합니다! 이것은 매우 유용합니다. 귀하의 제안에 따르면 이 설정이 통합 테스트에 적합하다고 생각합니다. 이러한 부분이 함께 작동하는지 확실히 알고 싶습니다.

인증 방법으로 oAuth만 사용하고 있습니다(사용자 이름/비밀번호 없음). 테스트 클라이언트를 만드는 방법에 대해 자세히 알고 싶습니다. 전체 oAuth 흐름을 진행하고 싶지는 않지만 테스트에 사용할 수 있는 토큰을 하드코딩하도록 제안하셨습니다. 테스트 클라이언트를 만드는 데 도움이 될 만한 리소스를 추천해 주시겠습니까?

현재 프로젝트에서 SailsJS v11.0을 사용하는 데 도움이 된다면. 내 서버를 시작하고 고정 장치로 메모리 내 데이터베이스를 생성/채우는 부트스트랩 테스트 파일 이 있습니다. 테스트 클라이언트를 생성하기에 적절한 장소가 아닐까요?

다시 한 번 감사합니다. 지식을 기꺼이 공유할 수 있는 사람들을 찾는 것은 정말 멋진 일입니다.

@rhewitt22 , 제 경우 테스트 클라이언트는 올바른 페이로드와 비밀 키로 서명된 만료되지 않는 JWT 토큰을 만드는 것만큼 간단했습니다. 도움이 될 수도 있습니다.

OAuth에서는 인증 흐름에 따라 다르다고 생각합니다. 특정 권한이 있고 만료되지 않는 최종 액세스 토큰을 생성할 수도 있으므로 매번 흐름을 거칠 필요가 없습니다.

해당 토큰이 프로덕션 시스템에서 많은 권한을 부여하는 경우 테스트에서 만료되지 않는 토큰을 하드코딩하는 것에 대한 보안 문제에 주의하십시오. 그러면 잠재적인 공격자는 액세스 권한을 얻기 위해 이 토큰만 필요합니다. 특정 클라이언트에 대한 액세스 권한을 부여하는 방법이 필요할 수 있으며 테스트를 실행할 때 테스트 클라이언트 또는 토큰에 대한 액세스 권한을 부여할 수 있습니다. 모든 것이 의미가 있기를 바랍니다.

@월링

조언 해주셔서 감사합니다!

테스트에서 oAuth 흐름을 건너뛰고 가짜 사용자를 만들고 프로덕션에서 사용하는 것과 동일한 JWT(만료 포함)를 부여했습니다. 모든 테스트를 통과했고 저는 매우 행복한 캠퍼입니다.

:스마일: :스마일: :스마일:

내 앱에서 작업하고 개발 서버를 보면서 oAuth 부분이 예상대로 작동하는지 확인할 것입니다.