TIL #43. unit test, 소셜로그인(Session)

ceres·2020년 3월 10일
0

TIL

목록 보기
15/34

(20/3/10)

session. unit test

우리가 테스를 하지 않으면 유저가 테스트 한다. 는 마음가짐
시스템 테스트 시 3가지 방법 존재

참고: stackoverflow

UI Testing/ End-To-End Testing

가장 오래걸리고 가장 비싸다.
결과물을 종합적으로 테스트하는 방법. 대부분 프로젝트 마지막에 한다. 직접 UI도 띄우고 서버도 연결해보고 실행까지 해본다.
테스트 준비시간이 걸리고 사람이 직접해야하기 때문에 비싸다.
그래도 다행이 UI 테스트도 요즘 많이 자동화가 진행되었다.

장점

가장 직관적이다.

단점

  • 문제 발생-> 프런트/백 문제인지 발견 -> 어느 사람 문제인지 발견 -> 문제 해결 -> 해당문제가 해결됐는지 다시 테스트
    : 문제를 찾는 시간도 해결하는 시간도 오래걸린다.

  • 배포
    1) 배포를 한번만 하진 않는다. 배포 한 후에도 기능을 추가하고 문제를 해결하다 보면 배포하는 횟수가 늘어남. 그 과정에서 많은 사람들을 거침.

2) 버그 발생할 확률 높음.
배포를 반복하다보면 나중에는 새로 추가한 기능 위주로만 테스트를 진행하게 되고 전체적인 테스트를 진행하지 않게된다. 그렇게 되면 기존 것에서 버그가 생긴다. 당연히 테스트를 하지 않았기 때문에 그곳에서 발생할 가능성이 크다.

Intergration Testing

내가 담당한 부분만 띄워서 테스트 하는것. end to end 많큼 비싸지는 않지만, 여전히 비쌈. 여전히 서버를 띄워야하고 사람이 직접 확인해야하기 때문.
프로젝트 기간에 가장 많이 하는 테스트일것이다.

Unit Testing

가장 작은 단위를 test함. 코드에서 가장 작은 단위는 함수. 이 함수를 테스트 하는 것.
테스트를 하는 코드를 짜야함. 어떻게 보면 코딩에 연장이다. 하지만 실제 사용되는 코드가 아니라 내코드를 테스트하는데에만 사용된다.
unit test는 비용이 훨씬 적다. 이유는 사람이 실행하는 것이 아니라 코드만 짜놓으면 자동으로 실행되기 때문이다. 단점은 코드를 짜야하기 때문에 그만큼 오버해드가 존재한다. 실제 기능보다 유닛코드가 구현하기 더 복잡한 경우도 있다.

Test Pyramid: 10% E2E/ 20% Integration/ 70% Unit

대부분은 unit test로 구성되어있고, 마지막에 확인할 때만 E2E, Intergraion test를 진행한다. unit test 에서 문제가 발생하면, 누구의 문제인지 찾느라 시간을 보낼필요없음
unit test는 당연히 내 문제일 것이고, 에러도 보통 명확하다.
버그는 있을 수 밖에 없다. unit test로 내 선에서 버그를 잡는 것이 좋은 개발자이다.
실제코딩:unit test = 시간분배 5:5
기능구현 만큼이나 unit test가 중요하다.
단기적으로는 unit test를 무시하고 기능을 구현하면 빨리 기능을 구현한 것 처럼 보이지만, 시스템 규모가 커지고 팀이 커질 수록 unit test를 무시하면 전체적인 공수가 커진다.

unit test 방법

  1. 복합적으로 검사해야한다.
    1 = happy test 로그인시 제대로 된 아이디, 비번을 넣으면 로그인이 성공되는지 확인하는 test
    2 = unhappy test 로그인시 잘못된 아이디, 비번을 넣으면 로그인이 실패되는지 확인하는 test
    0 = 빈값, 아주 큰 값을 넣어보는 test
    0은 예외케이스 여서 optional이지만, 1, -1은 꼭 test 해 주어야한다.
  1. 독립적으로 짜야한다.
    하나의 유닛테스트가 실행했을떄 다른 유닛테스트에 영향이 가면 안된다.
    테스트 끼리는 의존성이 없어야한다.
    테스트 후에 유닛테스를 지워야한다.

  2. 빨라야한다.
    유닛테스트에서 실제 요청을 보낸다던가, 타임을 걸어 놓으면 안된다. 빨리 실행해야한다.
    socaial login시 kakao에게 실제 api를 요청하면 안된다. 요청은 e2e test 할때 해라.
    외부 요청은 marking 처리한다. 실제 요청이 오지 않았지만, 요청이 온것 처럼 가정 후 로직을 테스트 한다.


Session. 소셜 로그인

일반적인 로그인 과정

1) 사용자가 PG(page) 에서 로그인 함
2) 백엔드에게 id, pw 전달
3) 백엔드에서 우리 DB에 해당 id,pw 있는지 확인
4) 회원인것 확인되면 백엔드에서 직접 발행한 JWT token을 프런트에게 보냄
5) 프런트에서 token 저장
6) my page 이용 가능

소셜 로그인 과정 (카카오)

1) 사용자가 PG(page) 에서 카카오로 로그인 함
2) 해당 PG에서 카카오 api 호출
3) 카카오에서 PG에 token 보내줌
4) 프런트는 카카오에서 받은 token을 백엔드(우리서버) 에게 보내줌
5) 백엔드는 카카오 api 호출 후 token 보냄

- 백엔드: 나 이 토큰 받았어 얘 누구야? 

6) 카카오에서 토큰 확인 후 id, email, 네임 등을 보내 줌

- 카카오: 얘 우리 회원 맞아 정보 보내줄게
<여기서 주의할 점!>
-카카오에서 토큰을 url뒤에 붙여서 보내줌. 하지만 토큰은 보여지면 안됨
	ex) localhost/auth?토큰이름
-> 토큰을 메인url로 받지말고 auth url로 받음
	ex) localhost/main으로 받지 말고, localhost/auth로 받음
-> 바로 백엔드에게 token 보내주고
-> clientpage를 main page로 이동  

7) 우리 DB에 해당 id가 있는지 확인

- 회원가입의 경우 카카오에서 받은 정보를 데이터로 저장

8) 우리 DB에 있다면 백엔드에서 직접 발행한 JWT token을 프런트에게 보냄
9) 프런트에서 token 저장
10) my page 이용 가능

소셜로그인시 주의할 점

소셜로그인은 소셜(FB,Google,Naver,Kakao ect)의 resource server를 사용하는 것. 소셜의 입장에서는 남이 우리것을 쓰는 것이 됨. 당연히 보안에 신경을 써야한다.
그렇기 때문에 front는 소셜로그인을 사용할 때에 해당 소셜로그인에 사용등록을 해야한다.
kakao의 경우kakao developer sever에 등록해야한다. 등록내용은
1) 우리가 만든 app 이름
2) 해당 소셜의 어떤 서비스를 사용하는지
(로그인, 지도, 캐린더, 메모 등 소셜에는 다양한 서비스가 존재하는데 그 중 어떤 것을 사용하는지 명시해야하는 소셜이 있다.)
3) 호출할 곳이 어디인지. api, 도메인 주소를 의미한다.
ex) local:3000 (프런트의 경우 본인 로컬 호스트 쓰면 된다.)
4) redirect url 토큰을 보내줄 url이다.
소셜에서 이 url 뒤에 토큰을 붙여서 보내준다.
localhost/auth 라고 입력 -> 소셜에서 localhost/auth?토큰 보내줌
위에서 말한것 처럼 토큰은 보안상 안보이게 하는 것이 좋기 때문에 redirect url은 메인페이지 url을 사용하지 않는것이 좋다.

소셜로그인시 필요한 endpoint

소셜에서 토큰을 받아 올 수 있는 한개의 endpoint만이 필요하다.
cf) 우리 서버에서는 login, sigup 2개의 endpoint가 필요하다.
총 합 최소 3개의 end-point가 필요하다.

0개의 댓글