내가 짠 코드가 작동하는지 확인 하는것 - 테스트
E2E - end to end / UI 테스트
직접 UI를 통해 테스트 하는 것 인력이 모자라는데, 급할 때 사용 모두 연결이 된 후에 테스트 가능 / 비용, 시간이 많이 든다.
항상 반복해서 하기 힘들다. 새로 변경 된 기능 위주로 테스트 하게 된다.
장점: 테스트 하기 직관적이고 쉽다. 가장 확실한 테스트 방법
마지막에 최종적으로 확인할 때만 하는 것이 좋다.
Integration 테스트 - 백엔드에서 엔드포인트 확인 / 서버를 실행 시키고 포스트맨 같은 것으로 호출하여 확인
장점: 테스트 하기 직관적이고 쉽다.
E2E 보다는 비용, 시간이 적게 들지만 역시 반복해서 하기 힘들다는 단점이 있다.
Unit 테스트 - 함수를 테스트. 함수 호출. 함수를 호출하는 코드를 짠다..?
input을 했을 때 원하는 output이 나오는지 확인
단점: 테스트를 하는 코드를 짜야 한다.
장점: 자동화가 된다. 코드를 한번 짜 놓으면 다음에 원할 때 쉽게 실행시킬 수 있다. 사람이 하는 것이 아니라 훨씬 빠르다. 버그를 발견했을 때 버그를 고치는 비용이 저렴하다. 버그를 발견한 그 부분만 수정하면 되기 때문. 대부분의 버그는 Unit 테스트에서 수정.
테스팅 피라미드
git-rebase
merge commit 깃이 봤을 때 다른 두 브랜치가 합쳐질 때
fast forward 깃이 봤을 때 브랜치가 하나인데 변경 사항이 있을 때
git-rebase / merge commit의 기능은 같다.
history를 깨끗하게 하기 위해서 git-rebase를 한다.
commit의 history를 보기 편하다.
merge commit의 경우 최종 코드에서 conflict가 난다. 1번만
git-rebase에서의 conflict는 최악의 경우 commit한 수 만큼 conflict가 날 수 있다.
git squash: 여러 개의 commit을 하나로 합쳐 rebase한다. 어떤 기능을 개발했는지 알기 쉽고 돌리기에도 더 쉽다. rebase와 함께 사용
rebase-i
rebase는 master에서 pull을 한 뒤 rebase를 해도 되고, 작업 했던 branch에서 해도 된다.
master 브랜치에서 작업:
git rebase -i master feature/브랜치 명
(목적브랜치 / 대상 브랜치 명시 해줘야 한다)
squash 처음 commit 부터 마지막 commit까지 돌면서 충돌이 있는지 확인하고 합친다
맨 처음은 pick
나머지는 squash나 s를 입력
squash한 후 conflict가 나면 conflict 해결한 후 add까지만 해주면 된다.
git add .
git rebase --continue
남기고 싶은 commit 메세지로 수정
git rebase --abort: rebase 자체를 중단.
push를 할 때 에러가 발생한다면 git push -f 옵션으로 push를 해준다.
rebase를 제대로 했다면 commit은 1개여야 한다.
marginNone="true"
