[NEXTSTEP] ATDD 과정 2주차 피드백, 3주차 시작

 

2023.07.09 - [공부 기록] - [NEXTSTEP] ATDD 과정 1주차 피드백, 2주차 시작

[NEXTSTEP] ATDD 과정 1주차 피드백, 2주차 시작

 

이번 주차에는 라이브 코딩이 포함 되어 있어서 내용이 적다.

 

2주차 피드백

• 인수테스트 뿐 아니라 단위 테스트도 같이 고민하는 주차였다
• 테스트에서만 사용되는 프로덕션 코드?
  • 테스트만을 위한 프로덕션 코드는 지양
  • 하지만 과하게 사용하는 것이 아니라면 제한적으로 허용 (우리의 정신 건강을 위해)
    • 생성자, stubbing, reflection
• 의존은 무조건 나쁜가?
  • 아니다
  • 의존이 없으면 하나의 객체가 모든걸 다 처리해야 함
  • 변경 요구사항이 발생하면 복잡해짐
  • 적절한 범위로 책임을 나누는게 좋음
  • 불필요한 의존은 제거 대상

통합 테스트

• 단위 테스트로 충분한가?
  • 특정 단위에 대한 검증이기 때문에 단위 테스트에만 의존한다면 단위들이 유기적으로 동작하는지 확인하기 어렵다
  • E2E 테스트를 통해 이를 보완할 수 있지만 단위들이 외부와 연동 되는것을 확인 할 필요가 있을 때 통합 테스트가 도움이 된다
• DB, 외부 서비스 등과 연결이 잘 되는지 확인 할 때 많이 사용한다
• 넓은 의미 VS 좁은 의미
  • 넓은 의미
    • E2E도 넓게는 통합 테스트이다.
    • 검증 대상, 테스트의 목적에 따라 테스트 이름을 붙이기 때문
  • 좁은 의미
    • 데이터베이스 테스트
    • 외부 라이브러리 테스트
      • 외부 라이브러리의 기능을 검증 할 필요는 없지만 그 부분을 활용하는 로직에 대한 검증은 필요 할 수 없음
      • 외부 라이브러리는 변경할 수 없으므로 실제 객체를 활용하는 것을 추천
• 관리 의존성 VS 비관리 의존성
  • 관리 의존성
    • 우리 어플리케이션 기준으로 관리 되고 있는 대상
    • 실제 대상으로 테스트 하는 것을 추천
  • 비관리 의존성
    • 우리 어플리케이션 기준으로 관리 되고 있지 않은 외부의 대상
    • 대체를 해서 테스트 하는 것을 추천
  • 의존성 테스트 방법
    • 실제 외부 의존성
    • Stub 대체
    • Fake 대체

---

 

https://github.com/next-step/atdd-subway-path/pull/608

🚀 2단계 - 지하철 구간 제거 기능 개선 by ktae23 · Pull Request #608 · next-step/atdd-subway-path

2주차 미션은 구간 추가 및 제거 기능 개선이었는데 구간의 규칙에 따라 추가하고 나누는 동작을 깔끔하게 분리해내는 것이 어려웠다.

현업과 유스콘 발표준비, 그리고 멘토링까지 하면서 수업을 들으려니 체력이 떨어져서 이번에는 2주나 되는 기간이었지만 부랴부랴 미션해서 3단계를 마치지 못했다.

 

이 글을 작성 한 뒤 유스콘 발표준비 후 3단계 미션과 3주차 1단계 미션을 끝내려 한다.

 

 

 

728x90

3주차 미션 설명

외부에 의존하는 인수 테스트 예시 (자료 참고)

• 서드 파티 로그인
  • Oauth 2.0 (Authorization Code Grant)
  • 구현해보기 (라이브 코딩)

인수테스트와 인증

• 인수 테스트에서 갑자기 인증?
  • 인수 테스트는 시나리오 기반 요구사항을 검증하는 테스트
  • 앞선 단계에서는 고려하지 않았지만 시나리오에는 “누가”라는 정보가 포함 되는 경우가 많음
  • 행위자가 누구인지에 따라 시나리오 흐름과 결과가 달라짐
• 인수 테스트에서 인증을 고려할 때 고민해야 할 점
  • 어떤 인증을 이용할 것인가?
  • 인수 테스트에서 인증 정보를 어떻게 할 것인가?
  • 인수 테스트에서 로직에서 인증 관련 로직을 어떻게 관리할 것인가?

인증과 인증 도구

• 인증 방식
  • 세션 기반 인증 프로세스
  • 토큰 기반 인증 프로세스
  • OAuth 2.0

인증 정보 전달 방법

• 인증 스킴
  1. Basic
     1. base64를 이용하여 인코딩된 사용자 ID/비밀번호 쌍의 인증 정보를 전달
     2. 보안을 위해 HTTPS (TLS) 연결 위에서 발생되어야 함
  2. Bearer
     1. bearer token이라는 보안 토큰을 활용하는 인증 스킴
     2. Oauth2.0에서 사용하기 위해 만들어짐
• HTTP 인증 프레임워크
  • RFC에서 정의한 방식
  1. 데이터 요청
  2. 인증 요구
  3. 인증 정보 포함 데이터 요청
  4. 데이터 응답

인수 테스트 인증 도구

• RestAssured에서 사용하는 RequestSpecification.auth()
  • form("email@eamil.com", "password")
  • basic("email@eamil.com", "password")
  • oauth2(accessToken)