20240503 맘대로 해봐라! 3차 프로젝트 FlowNary SNS 14일차

2024.05.03 역할분담, 선생님2차회의, Test : Unit / Integration / E2E
4교시 회의
2024.05.02 진행한 Unit test 결과 공유
각자 진행하고 있는 구현에서의 오류 공유
해결방법 단체 고민 및 토의

----------------------------------------------------------------------------------
작업 내용

이병학 : board 검색 데이터 가져오는 건 했고 무한스크롤 해볼게요
윤영준 : DB (User) , DB (reply , re_reply) 하겠습니다.
안순현 : 설정 - 생년월일 수정, 버튼 반응형 수정 하겠습니다
곽주영 : Board 다중img 업로드 완료 / carousel & reply rContents null 수정
정성한 : 챗봇 - 메시지 응답 변경 수정
이윤주 : 3주차 주간보고서 제출 / 4주차 주간보고서 작성 / Setting UI 수정

- 부장 역할분담 정리
벡엔드(이병학) 
프론트엔드(정성한) 
백및프론트교육(안순현) 
디비(윤영준) 
QA(곽주영) 
기획(이윤주)

---------------------------------------------------------------------------------------

선생님 2차 회의 후 결과
- PASS API 가격 확인하기 (나이스 평가정보)
- 파이어베이스 이메일 인증 API 가격 확인하기 (회사마다 얼마씩 받는지)
- 성한 : 챗봇 - 버튼 클릭시 도움말 표시 구현성공, 대화 기능 구현 중 입니다
- 순현 : 로그인(login.jsx) - localstorage를 통해 전체 페이지에 세션화
세팅부분(setitngDetail.jsx) - 세션 유저 정보에 따라 DB 값이 불러와지고, 닉네임과 전화번호는 중복확인을 함. 비밀번호 부분도 있으나 따로 구현할 예정 (비밀번호 확인을 통한 진입)

npm i dayjs 
npm i react-responsive-carousel 
npm i @mui/x-date-pickers

이거 3개 설치하세요

검색 결과 창에 아무것도 없을 경우 예외 처리 해야합니다

이병학 : 
1. visual code의 좌상단 메뉴 부분의
파일 → 기본 설정 → 설정 클릭
상단 설정 검색에서 setting 입력하고 파란 글씨의 setting.json에서 편집 클릭

2. 아래쪽에
"javascript.validate.enable": false
추가

---------------------------------------------------------------------------------------

Test의 종류
테스트에는 단위 테스트 / 통합 테스트 / 종단 간 테스트가 있습니다.
각각의 특징에 대해 알아보며 웹 백엔드의 테스트에는 어떻게 적용되는지 알아보도록 하겠습니다.

[1]. Unit Test (단위 테스트)

단위 테스트는 프로그램의 기본 단위가 되는 모듈을 테스트하는 것으로, 모듈 테스트라 하기도 합니다. 테스트의 초점은 개발자가 개발한 모듈이 의도대로 동작하는가 아닌가 에 있습니다.

테스트 방식은 모듈 내의 데이터 흐름에 대한 예외 케이스를 작성하고, 이를 통과하는지 확인하는 식입니다. 이때, 필요하다면 가짜 객체(Mock Object)를 사용해 테스트를 진행합니다.

백엔드에서의 레이어가지고 이야기 하자면
단위 테스트를 진행하는 레이어는 serviece, controller 등 각각 내부 기능들 입니다.

[2]. Integration Test (통합 테스트)

통합 테스트는 단위 테스트가 끝난 모듈과 외부 라이브러리 또는 DB와 같이 개발자가 변경할 수 없는 모듈까지 함께 진행하는 테스트입니다. 테스트에 초점은 모듈 간 상호작용이 정상적으로 수행되는가 아닌가 에 있습니다.

테스트 방식은 어떤 요청에 대한 결과를 기대값으로 지정해 놓고, 해당 요청을 보냈을 때 예상한 결과값이 제대로 돌아왔는지 확인합니다.

웹 백엔드를 기준으로 통합 테스트를 진행하는 레이어는 Router — Controller — Service — Repository — DB 까지입니다.

[3]. E2E Test (종단 간 테스트)

종단 간 테스트는 실제로 사용자가 서비스를 사용하는 상황을 테스트하는 것으로, 인수 테스트와 같은 의미로 사용되기도 합니다. 테스트의 초점은 소프트웨어 내부 구조가 아닌 비지니스적 시나리오대로 잘 동작하는가 아닌가 에 있습니다. 또한, 테스트의 주체가 단위 테스트와 통합 테스트는 개발자이지만, 종단 간 테스트에서는 개발자 이외에도 QA 등이 포함될 수 있습니다.

테스트 방식은 비지니스적 시나리오를 정리해서 실제로 요청을 보내고, 시나리오대로 요청에 대한 결과가 오는지 확인합니다. 웹 백엔드를 기준으로 종단 간 테스트를 진행하는 레이어는 Router — Controller — Service — Repository — DB 까지이며, 통합 테스트와 테스트가 진행되는 레이어는 같지만, 다른 점은 테스트의 목적 그리고 테스트하려는 부분이 코드 내적인 부분인지 외적인 부분(비지니스적 시나리오)인지에 있습니다.

Test의 크기
이번에는 각 테스트에 대한 테스트의 단위의 크기와 비용에 대해 알아보자. 아래 그림으로 보면 (UI = E2E, Service = Integration 을 의미합니다.) 테스트 단위의 크기와 비용에 관한 상관 관계를 알 수 있습니다.


E2E → Unit 으로 갈수록,

테스트 단위의 크기가 작아지고,
테스트를 위한 비용이 감소한다.
Unit → E2E로 갈수록,

테스트 단위의 크기가 커지고,
테스트를 위한 비용이 증가한다.
이렇듯 테스트 별로 목적과, 테스트 되는 레이어, 테스트를 진행하는데 들어가는 비용 등이 달라지는데, 프로젝트에 어떤 Test를 얼마만큼 적용해야 하는 것일까요?

Test의 비율
Google Test Automation Conference에서는 아래와 같은 테스트 비율을 제안했습니다.


사진은 Testing Pyramid라 하는데, 프로젝트에 적용할 단위 / 통합 / 종단 간 테스트의 비율을 나타냅니다. 각각에 대한 수치는 아래와 같습니다.

E2E — 10%
Integration — 20%
Unit — 70%
권장 테스트 비율 말고도 테스트 비율에 대한 안티 패턴에 대해서도 주의를 하는데, 안티 패턴의 모양은 역 피라이드 또는 모래시계 모양입니다.

Test 라이브러리
이제 어떤 테스트가 있고, 어떤 목적을 가지고 어떻게 진행되는지, 어느 레이어까지 테스트가 되는지 알았습니다.
Nodejs 환경에서 테스트를 진행하기 위한 라이브러리에는 무엇이 있는지 알아보도록 하겠습니다.( 설정 및 사용법에 대해서는 다루지 않았습니다.)

[1]. Unit Test (단위 테스트)

단위 테스트를 위한 라이브러리로는 Jest와 Mocha가 있습니다. 둘 다 인기가 많은 라이브러리이지만, Mocha 단일 라이브러리로는 단위 테스트를 진행하기 힘든 반면, Jest는 단일 라이브러리로 단위 테스트를 진행하기에 무리가 없다. (해당 글 참조)

따라서, Unit Test를 위한 라이브러리로는 Jest를 권장합니다.

[2]. Integration Test (통합 테스트)

웹 백엔드의 통합 테스트에는 http요청과 해당 요청에 대한 예상 결과를 확인하는 기능이 필요합니다. 이러한 기능을 제공하는 라이브러리로는 supertest, chai-http 등이 있지만, supertest가 압도적으로 사용량이 많고 꾸준한 업데이트를 하고있습니다.

따라서, Integration Test를 위한 라이브러리로는 supertest를 권장합니다.

[3]. E2E Test (종단 간 테스트)

웹 백엔드의 종단 간 테스트는 실제 http 요청을 브라우저 또는 서버를 통해 보내는 테스트입니다. 통합 테스트에서는 라이브러리를 사용해 가상의 서버로부터 http 요청을 보냈고, 테스트를 진행하는 사람도 개발자였지만, 종단 간 테스트에서는 가능하면 실제로 요청로 진행하며, 진행하는 주체는 개발자보단 QA쪽에 있습니다. 이렇다보니, 실제 환경(브라우저 또는 실제 서버)에서 데이터를 보내고 받는 기능이 필요한데, 이러한 기능을 제공해주는 툴로 셀레니움 있습니다.

셀레니움은 일종의 매크로 프로그램으로, 브라우저에서 진행되는 모든 작업을 자동화할 수 있습니다. 이런 자동화를 통해, 브라우저는 조작하여 실제 유저가 요청 및 응답을 받는 것처럼 종단 간 테스트를 진행할 수 있습니다.

TDD
TDD는 Test Driven Development 의 약자이며, 직독직해를 하면 테스트 주도 개발 이라는 의미입니다. 말 그대로 TDD는 테스트 코드를 먼저 작성하고, 이에 맞춰 실제 서비스 코드를 작성하는 방식의 개발 방법론입니다.

주차별_주간보고서_3주차.xlsx

0.03MB