백엔드는 유닛테스트를 하고 해야 하고
백, 프론트 둘다 pr 할 때 리베이스를 해서 날려야 pr이 된다.
Testing
얼마나 중요할까?
많은 개발자들이 중요한 건 코딩 이라고 생각하는데 그건 기본이고 그보다 더 중요한 것들이 많다.
-남들이 같이 일 하고 싶은 개발자가 되는 것
-내 코드가 제대로 작동이 되는가를 테스트 해봐야 한다.
작동이 되지 않으면 코딩의 의미가 없다. 제대로 구현이 되어야 의미가 있는 것.
코딩에 비해서 재미가 없다고 생각하기 때문에 . 내가 테스트를 안하면 유저가 테스트를 한다.
내가 테스트를 해서 문제가 발견이 되면 고치면 되지만 유저가 발견하면 이미 데미지가 있다. 유저 입장에서 실망이 생기고 불편함이 생기고 피해가 갈 수도 있다.
commit은 책임감이 있는 행위이다. 내가 push를 날릴 때는 내 코드에 대해서 모든 검증이 끝났다는 상태일 때 해야 하는 것.
UI Testing/End-to-End Testing
말그대로 UI단에서 테스팅을 해보는 것
end to end 처음부터 끝까지 해보는 것
모든것을 연결 시킨 다음에 사람이 직접 다 해보는 것.
로그인 해보고 검색창에 쳐서 결과가 제대로 나오는지 확인해보는 마지막 결과물을 종합적으로 테스트 해보는 것
UI 테스팅은 기업 입장에서 비싼 테스트이다. (비용과 시간이 많이 든다.)
사람이 테스트를 해보아야 하고 테스트를 하기 위한 준비가 많이 걸린다. ( 서버 띄우고 백, 프론트 연결, 배포할만한 환경을 구축한 다음에 테스트 해야 하므로)
대신에 가장 직관적이고 확실한 테스트이다. 사람의 눈으로 확인을 해보는 것이니까
많은 스타트업들이 ui test에 의존을 많이 한다. 총 4명의 사람들이라면 초기버전을 만들고 그 배포를 하기 전에 테스트를 해본다.
만약 우리가 테스팅을 하다가 버그가 생겼다면? 문제를 해결하는 과정이 ( 백엔드 문제인지 프론트 문제인지 어디쪽에서 발생한 문제인지에 대한 파악. 그걸 파악하고 나면 누구의 코드인지 파악. 누가 고쳐야 하는지. 그 다음에 또 다시 테스트를 해야 한다. 해당 문제가 제대로 고쳤는지를 확인해보아야 한다. 이래서 어려움
시작하기도 어렵고 문제해결도 복잡하고 시간이 걸리기 때문에.
-그런데 우리는 배포를 빨리 빨리 할 수 없다. ( 2주 후에 업데이트해서 배포 한다고 했을 때? 그 전에 또 테스트를 할것이다.)
그런데 이런게 계속 있다면? 점점 시간이 흐를 수록 추가한 기능만 테스트 하게 된다. 그런데 그러면 새로운 기능은 버그가 없는데 기존의 코드에서 버그가 발생한다. 테스트를 안했으니까!
- 제일 직관적이고 가장 마지막으로 확실하게 확인할 수 있지만 가장 비싸다
Integration Testing
서버를 띄워서 딱 한 부분만 테스트 하는 것.
내가 담당하는 쪽만 해보는 것.
end to end 만큼 비싸지는 않지만 인간이 하는 것이기 때문에 비슷함
unit testing
unit이 단위라는 뜻이기 때문에 . 여기서는 가장 작은 단위 ( 코드 에서의 가장 작은 단위 - 함수)
유닛테스트를 하려면 코드를 짜야함
내 코드를 테스트를 하는 코드를 짜는 것이 유닛 테스트
실제 사용 되는 코드가 아닌 내 코드를 테스트 해주는 코드라고 생각하면 된다.
실행 비용이 훨씬 가격이 저렴하다. ( 사람이 실행하는 것이 아닌 자동화가 가능하기 때문에)
내가 원할 때마다 바꿀 수 있고 아무리 테스트 케이스가 많아도 완료를 시킬 수 있기 때문에)
모든 테스트를 통화하면 심각한 버그는 없겠구나 하면서 출시 함.
단점 : 테스트를 하는 코드를 짜야 하기 때문에 그에 대한 부담이 있음
의외로 실제 기능 보다 유닛 테스트를 구현하는 것이 어려운 경우가 있음
유닛 테스트를 짜는 것도 task에 포함이다. ( 책임감)
유닛 테스트가 있는 게 생산성, 효율성 에서 큰 차이가 있다.
테스트를 하지 않으면 어쨌든 그 문제는 계속해서 내 앞에 존재한다.
버그는 있을 수 밖에 없다. 인간이니까. 테스트를 통해 그런 것들을 잡는 것 뿐이다.
5대 5 정도로 생각해야 한다. ( 물론 현실적으로 하기 힘들긴 하다.)
하지만 마음가짐 만큼은 그만큼 유닛테스트의 중요성을 인식하고 있어야 한다.
미국에서는 유닛테스트를 많이 함. 그런데 우리나라 개발 문화에서는 유닛테스트를 가볍게 생각하는 느낌이 있다. (아마 빨리 빨리 문화 때문에?)
회사가 커질 수록 버그에 의한 보수 비용과 손해는 더 크다.
테스트 할 때 중요한 것
test case 를 어떻게 짤 것인가?
1
0(예외적인 케이스)
-1 (happy path)
나오면 안되는 값을 확인 해본다.
http : stateless
유닛테스트도 독립적으로 짜야 함 유닛테스트에서 생성하는 데이터들은 테스트가 끝나면 지워줘야 한다.
이렇게 함에 따라 다른 테[스트에 영향이 가면 안된다
테스트는 빨리 진행되게 해야한다.
실제로 요청을 하지 않고 마킹.
Rebase
base 다시 한다?
자꾸 merge commit을 하면 지저분해짐
( 장점
그래서 rebase를 해야 한다.( base를 다시 잡아주는 것)
리베이스는 커밋하나하나가 올라단다.
squash 합쳐버리는 것 ( 찌부시키는거) - 그래서 커밋을 할때 여러개를 합쳐 하나가 되어야 한다.
-forcebranch : 무조건 내 브렌치에서만 해야 한다.
