[스프린트4] - 19주차 Day3 협업, API, 테스트 및 문서화 전략

프로젝트를 시작 할 때 팀원들과 어떤 규칙을 가지고 임해야 하는지, 백엔드와 프론트엔트 간에 공유해야 할 사항과, 아닌 것은 뭔지가 항상 헷갈려서 API 호출 시에 문제가 발생했던 적이 있었습니다!

 

그렇기 때문에 이번 강의가 많은 도움이 되어서 캡쳐 해 놓았던 부분을 중심으로 정리 하고자 합니다. 

 

전체 응용의 구성 

👾 Frontend

• React 응용으로 만들어져 UI(User Interface)에 해당하는 부분을 서비스
• Backend로 향하는 API 호출은 브라우저의 js 실행에 의하여 이루어짐 
  - FE에서 작성된 js 코드가 사용자의 브라우저에서 실행되어, 서버 측의 BE 시스템과 통신하기 위한 API 호출을 발생시킨다

👾 Backend

• Express 응용으로 만들어져 데이터베이스를 이용한 데이터 모델을 서비스
• JWT(JSON Web Token)를 이용한 사용자 인증을 통해 데이터 접근을 보호
• CORS(Cross-Origin Resource Sharing) 정책을 통해 악의적인 접근을 방지

👾 Database

• `prgms_notes` 라는 이름의 데이터베이스에 두 개의 테이블을 포함

설정해야 할 것들

👾 Frontend

• Backend의 API URL
  - API URL을 코드에 포함하여 클라이언트에서 올바른 endpoint를 구성할 수 있도록

👾 Backend

• DB (host, database, user, password)
  - 직접 (connector 이용) 데이터베이스 접근을 할 수 있도록
• Frontend의 URL
  - CORS 정책에 의하여 특정 소스로부터의 접근을 허용할 수 있도록

 

URL 설정을 하면서 저는 endpoint, callback ... 이런게 너무너무 헷갈렸는데요

1. API URL:
   • API URL은 클라이언트 애플리케이션이 서버의 백엔드 시스템에 데이터를 요청하거나 서버에 데이터를 전송하기 위해 사용하는 엔드포인트 주소입니다. 이는 보통 HTTP 또는 HTTPS 프로토콜을 통해 서버에 요청을 보내는 URL입니다.
   • 예시: https://api.example.com/data, https://example.com/api/getUser
2. Frontend의 URL:
   • Frontend의 URL은 사용자가 웹 브라우저에서 접근할 수 있는 프론트엔드 애플리케이션의 주소입니다. 사용자는 이 URL을 통해 프론트엔드 애플리케이션에 접속하고 사용할 수 있습니다.
   • 예시: https://example.com, https://example.com/dashboard
3. Callback URL:
   • Callback URL은 주로 인증 과정에서 사용되며, 서버에서 클라이언트에게 인증 결과를 전달하기 위한 URL입니다. 일반적으로 OAuth 및 OpenID Connect와 같은 프로토콜에서 사용됩니다. 사용자가 외부 서비스에 로그인하고, 로그인이 성공하면 해당 서비스에서 사용자를 다시 애플리케이션으로 리디렉션하는 데 사용됩니다.
   • 예시: https://example.com/callback, https://example.com/auth/callback

각각 이런 차이가 있습니다 !!! (*＾▽＾)／

 

테스트 계획

1. 단위 테스트 (UT: unit test)
   - 모듈 단위를 독립적으로 테스트 할 수 있도록 mock 이용
2. 통합 테스트(IT : integration test)
   - (FE + BE + DB) 사이의 통합이 올바르지를 테스트 할 수 있는 방법을 계획하고 적용
   - 자동화 방법에 대해서 고민해 볼 필요(특히 데이터베이스의 상태 관리 방법에 주의)
3. 인수 테스트(AT: acceptance test)
   - 이 프로젝트에서는 Selenium을 이용한 E2E(end-to-end) 테스트를 적용
4. 스모크 테스트(ST: smoke test)
   - 배포 상태가 올바르지 검사(status code 만을 체크)

프로젝트의 요구 사항과 특성에 맞게 적절한 테스트 전략을 구축하는 것이 중요! 

 

문서화

• 기술적 요소 - 나(우리 팀)이 프로젝트의 기술적 요소와 환경을 잘 이해하고 있는지 점검 가능
• 일정 계획 - 진도 관리, 변화 대응에 중요
• 프로젝트 전체의 진척상황과 동적 대응의 가이드라인으로 활용
• (팀일 경우) 전체가 동의하고 공유할 수 있는 기술적/비기술적 합의 사항

 

테스트 데이터베이스 준비

• 가능한 한 데이터베이스에 의존성을 갖지 않는 상태에서 코드를 개발하는것이 좋다
• 어느 시점에 이르면 코드의 검증을 위해 데이터베이스의 상태가 필요
  e.g > 로그인 상태에서만 작동하는 기능 ... , CRUD 동작 검증 ...
• 스키마가 확정되어 있다면 데이터베이스를 조기에 마련하는것도 좋다
  그러나, 프로덕션(실제 운영) 데이터베이스를 테스트 목적으로 사용하는것은 권장하지 않는다.
  테스트 작업 중 데이터베이스가 변경되거나 테스트 작업으로 인해 데이터가 손상될 수 있기 때문 !
  >> 테스트를 위한 별도의 테스트용 데이터베이스를 설정하여 테스트에 활용하자!