[TIL] 5. 배포 사전 지식 / jest , cypress

 

1. 배포를 위한 숲을 그려보자! - Cloud-Provider
2. 배포하면 끝인줄 알았는데... 테스트는 또 뭘까? - Jest / Cypress / TDD
3. 다 끝난줄 알았는데.. 안전하지 못한 코드가 있었다니.. - isSubmitting
                                                                   → 위험한 로그 처리하는 것.

 

 

isSubmitting 내용은 다음에 다뤄보겠습니다.

 

 

---

 

 

배포 (세상에 공개하는 것!)

프로젝트 yarn dev 시 내컴퓨터에서 구동, 외부에서 접근(배포)

1. 내컴퓨터에서만 구동 :  yarn dev를 통해 ‘내 컴퓨터’안에서만 구동시켜 봤습니다.
2. 외부에서 접근 : 하지만 외부 다른 컴퓨터에서도 접근이 가능하고 싶다면 외부 컴퓨터를 빌려 배포를 진행해야 합니다. (내 컴퓨터로도 배포 가능하긴 합니다.)
3. why? : 물론 우리가 가지고 있는 컴퓨터로도 배포가 가능한데요.
   해당 컴퓨터를 24시간 구동시켜야하기 때문에
   외부 컴퓨터를 빌려 배포를 진행하는 것이 효율적입니다. (경제적 측면)

 

옛날 배포 방식에 대한 보완으로서의 현재 방식 :

서버컴퓨터와 DB컴퓨터를 직접 사용하여 진행했습니다.
이 방식에는 문제가 있습니다.

 

문제 :

사용량이 증가하게 될 경우 서버 컴퓨터에 무리가 생겨 부하를 분산 시켜주어야 합니다.

문제 해결 :

그렇기에 서버 컴퓨터를 하나 더 구매하여 분산시켜 주었습니다.

 

LB(LoadBalancer) :

LB를 사용해 각각의 컴퓨터의 사용량을 분산시켜 해결합니다. ( 사용량이 더 적은 서버쪽으로 안내.)

 

컴퓨터대여 (feat. CloudProvider) :

실물 컴퓨터를 구매하던 것을 이제는 CloudProvider 서비스를 사용하여 컴퓨터를 대여하게 되었습니다.
대표적으로
AWS(AmazonWebServices)
GCP(GoogleCloudPaltform)
Azure
등이 있습니다.

 

1. 컴퓨터 대여하여 그대로 사용 가능 : 이렇게 클라우드 서비스를 사용하여 컴퓨터를 대여하면 해당 컴퓨터 안에서 git clone, yarn dev 등 명령어를 그대로 사용해 배포를 진행할 수 있었습니다.

가상 컴퓨터를 빌리기 (gcp의 compute Engine-VM인스턴스 ) :

gcp의 compute Engine-VM인스턴스를 통해 가상 컴퓨터를 빌릴 수 있습니다.

1. 인스턴스 만들기 : 이 안에서 인스턴스 만들기를 통해 빌리려는 컴퓨터의 사양과 지역을 고를 수 있었고, 부팅 디스크에서 컴퓨터의 운영체제를 선택 할 수 있습니다. 가상 컴퓨터를 대여한 후 SSH를 통해 해당 컴퓨터에 접속할 수 있습니다. 이 컴퓨터를 24시간 꺼지지 않도록 설정하여 우리가 배포한 사이트가 항상 접근이 가능하도록 해줍니다.
2. 빌려 놓은 컴퓨터의 ip로 접속하는 방식은 ip 번호를 일일이 기억해야 하기 때문에 번거롭습니다. 따라서 구매한 도메인을 연결시켜 주어 도메인 주소를 통해 해당 사이트에 접속하게 될 경우 해당 ip로 변경해 접속할 수 있도록 해주어야 합니다. (네트워크 서비스 - Cloud DNS(Domain Name System) 에서 설정 가능)
3. 배포를 하게 될 경우 크게 두 가지 영역에 배포를 진행합니다. ( Storage / Frontend-Server ) :
   1. Storage : html,css,js 등을 Storage에 저장시킨 후 Browser에서 Storage에 접근하여 html,css,js를 다운로드 받는 방식을 위한 Storage배포와
   2. Frontend-Server : SSR이 필요한 페이지에 접근할 경우, Browser에서 Frontend-server에 접근한 후 Backend-server -> DataBase에 접근하기 위한 Frontend-Server배포입니다.
4. 로드밸런서(LB) : 주소(DNS)에 따라 어디로 접근하여 필요한 데이터를 받아올지가 나뉘게 되는 것인데, 이런 방식을 구분시켜주는 도구! 로드밸런서(LB)가 Browser에서 Storage 혹은 Frontend-server에 접근하기 전, 어디로 접근할지 판단하여 나누어 준다고 했습니다! 그렇기에 Storage/Frontend-server 앞에 붙여줍니다.

다시말해, 접속하는 도메인 주소에 따라 입력된 값을 LB가 판단하여 Storage로 연결시킬지, Frontend-server로 연결시킬지 구분해줍니다.

1. 방화벽 : 하지만 이 Frontend-Server에 아무나 접근하면 안되겠죠! 따라서 우리는 방화벽을 설정하고, 우리가 지정한 특정 접근으로만 방화벽이 열리게 설정해주어야 합니다.

오늘 배우는 배포의 개념을 잘 잡고 가지않으면 실제 배포를 진행할때 많이 힘들게 되니, 꼭 개념 정리를 하고 넘어가야 합니다.

테스트코드

테스트 코드란 : 테스트코드는 우리가 만든 프로젝트가 잘 구동되는지 하나하나 손으로 체크하는 것이 아닌 프로그램으로써 확인하는 방식입니다! 예시를 통해 테스트코드의 중요성을 알아봤습니다! 새로운 업데이트가 있을때, 예상치 못한 부분에서 발생할 수 있는 오류를 알 수 있었죠! 테스트코드는 안정적인 서비스 운영에 있어 중요한 부분이였습니다!

• 테스트 방법 :

테스트 방법에는 개별 기능을 테스트하는 단위테스트와 한꺼번에 테스트하는 통합테스트, 특정 루트나 시나리오가 있는 E2E테스트(End to End)가 있었죠!

테스트 코드를 진행할 수 있는 프레임워크가 있는데, 그 중 대표적으로 jest와 cypress가 있습니다. 1. jest ← facebook 단위테스트 ( 개별 기능 테스트 ) 2. cypress ← airbnb 통합 테스트 ( 한꺼번에 테스트 ) : E2E테스트 ( 특정 루트 or 시나리오 )

jest

테스트 코드 프레임워크 설치 :

우리는 Next에서 사용하기위해

1. 설치 명령어 : devDependencies에

jest testing-library/react testing-library/jest-dom 설치.

+) 이때, eslint 에러가 발생할 수 있기에, eslint-plugin-jest도 설치.

1. 설치 이후, 설정파일 만들기 : jest.config.js에 공식문서 내용(https://nextjs.org/docs/testing#jest-and-react-testing-library)을%EC%9D%84) 넣어주었습니다.
2. 마지막으로 테스트 명령어를 추가 : package.json안 script에 ”test”:”jest --watch”를 추가했습니다! 여기서 --watch는 테스트 진행 후 자동종료 되지않고, 변경사항이 생길때마다 테스트를 다시 진행하게하는 역할을 합니다!
3. 테스트 관련 파일들은 추후 헷갈리지 않도록 따로 폴더를 만들어 관리: test 기억나시죠? 보통 이런 테스트 폴더는 루트경로에 두어 관리하는 것이 추후 편할겁니다!
   1. 큰 단위 테스트 : describe(“어떤 테스트인지 설명”,()=>{}) 를 사용
   2. 작은 단위 테스트 : it(“어떤 테스트인지 설명”,()=>{})로 진행
   여기서 it 대신 test 로 사용하여도 됩니다! 기대값을 적어줄때는 expect()를 사용했죠! 그리고 결과로 나와야 하는 값을 toBe()안에 적어주었습니다!
   1. 단위 테스트 : 간단한 컴포넌트를 만들었고 출력되는 화면이 맞는지 체크했습니다. 가상화면 출력테스트를 위해 import 받았습니다. (testing-library/jest-dom/extend-expect)
   동일하게 it()를 사용했고 테스트 함수에는 해당 컴포넌트를 가상으로 렌더링 시켜주는 render()를 통해 우리가 만든 페이지를 실행시켜주었습니다.하지만 이 방식은 방대한 양의 UI를 체크하기에는 비효율적입니다.
   1. **snapShotTest :** 스냅샷 테스트는 해당 화면을 찍어 놓고, 이후 테스트를 진행할때 이전에 찍어 놓은 화면과 다른 부분을 찾아 알림을 주는 방식이였죠! 테스트 함수에는 rendering결과를 담아 expect(result.container).toMatchSnapshot()를 사용해
      • 기존 스냅샷이 있는 경우 :
        • 기존 스냅샷과 비교
      • 기존 스냅샷이 없을 경우 :
        • 새로운 스냅샷을 찍습니다.
4. 따라서 *snapShotTest를 사용하는것이 더 효율적입니다.*
5. 이후, 렌더링된 화면이 우리가 만든 내용과 동일한지 screen과 .getByText()를 사용해 화면 내 내용을 뽑아와 expect().toBeInTheDocument()를 사용해 화면에 출력되어있는지 확인했습니다.
6. 그 예시로 우리는 더하기 함수를 테스트했죠!(expect(result).toBe(8) 기억나시죠!) 실제 테스트는 yarn test 로 진행했습니다!

cypress

cypress테스트도 진행해봤습니다! cypress는 통합테스트에 적합했죠! 우리는 페이지 이동 테스트를 진행해 보았습니다!

1. 설치 :
   1. jest와 동일하게 devDependencies에 cypress 추가
   2. script에 ”cypress”:”cypress open”와 ”cypress:run”:”cypress run”을 추가
   3. jest와 충돌이 날 수 있기 때문에 jest.config.js에 testPathIgnorePatterns:[“<rootDir/cypress”]를 입력
2. 테스트를 위해 테스트코드를 만들기 전:
   1. cypress 열기: yarn cypress
   2. cypress 실행 : 또 다른 터미널을 열고 yarn cypress:run 명령어로 실행
   3. 실행시키게 되면 : 프로젝트 루트위치에 cypress폴더가 생기고, 내부에 integration(통합)폴더에 우리의 테스트를 작성하면 됐죠!
      1. 동일하게 it로 작성.
      2. 페이지 방문 : 테스트 함수에 cy.visit(“접속할 브라우저 주소”)로 페이지를 방문시킨 후,
      3. 페이지 이동 : cy.get(“button”).click()로 페이지 내 이동 버튼을 눌러주어 페이지를 이동시키고
      4. 체크 : cy.get(“div”).contains(“포함하고 있어야하는 내용”)으로 체크해 주었습니다!
      여기서 중요한 포인트는 사이트를 접속시켜주기 위해 yarn dev를 통해 서버를 열어 주어야 한다는 것이였습니다!