[Next Step] ATDD, 클린 코드 with Spring 8기 3주차 리뷰

🎈 테스트와 의존

ref : Next Step

의존은 무조건 나쁜가에 대해서 이야기했다.

물론 답은 아니다. 의존이 없으려면 하나의 객체가 모든걸 다 처리해야하고, 변경 요구사항이 발생할 때 복잡해진다.

이를 위해서 적절한 범위로 책임을 나누는게 좋고, 불필요한 의존 대상은 정리해야한다.

 

🔎 테스트와 관련한 궁금증

1.통합 테스트인 경우 외부 라이브러리를 테스트해야 할까?

 외부 라이브러리의 기능을 검증할 필요는 없다. 하지만, 그 부분을 활용하는 로직에 대한 검증은 필요할 수 있고, 외부 라이브러리는 변경할 수 없으니 실제 객체를 활용하는게 좋다.

ref : Next Step

의존성 테스트를 할때는 실제 외부 의존성을 사용하거나, Stub 혹은 Fake로 대체하자.

 

❤️ 3주차 후기

외부에 의존하는 인수 테스트 미션을 통해 외부 의존성에 대한 고민을 했던 것 같다. 

미션은 Github 로그인을 어떻게 테스트할건지 고민할 수 있는 로그인 미션이 주어졌고, 가이드에 따라 미션을 점차 진행해가면서 외부 테스트의 테스트에 대해서 자세히 알게됐다.

ref : Next Step

여기서 fakeController를 사용하고 url을 application 설정에 따라 테스트하는 방법을 사용했다. 

인증서버와 리소스 서버의 경우(여기서는 github) 내가 직접적으로 테스트하기에는 어려우니 fakeController를 미리 생성하고 테스트시에 url을 변경하는 방법이다.

test - application.properties

물론 test - resource에 application-properties를 만들거나, main에 prod 설정파일을 따로 만드는 2가지의 방법이 있지만, 개인적으로 별도의 프로필을 설정하는것 보다 test에 설정파일을 생성하는걸 선호한다.(물론 상황에 따라 다름)

그렇게 fakeController를 만든 뒤 실제 요청을 보내는 GithubClient 객체에서 url을 환경변수로 받아서 별도의 환경을 구축하는것이다.

 

아래는 다른 설정파일로 url을 설정하는 방법이다. oauth2에서 code를 받는 부분의 endpoint와 인증 후 token을 발급받는 endpoint를 설정파일을 통해 실제 서비스(github)에 요청을 보낼지, local에서 생성한 fakecontroller로 보낼지를 선택할 수 있다.

이를 통해서 ATDD에서 인증을 어떤식으로 테스트하고 우회가 가능한지 알 수 있었고, 실무에서도 적용하기 어려운 부분에 대해서 자세히 학습할 수 있었다.

 

🎁 RestAssured 인증 제공 종류

그리고 아래는 RestAssured에서 제공하는 인증이다.(출처 - NextStep)

 

1.HTML form

 

2.Basic Auth

 

3.Bearer Auth

 

4.Header를 추가한 인증