tdd( test driven development)
단위테스트(개별api를 테스트함)
통합테스트(api들의 묶을을 테스트함)
e2e test(진짜 유저가 사용한다고 가정하고 로그인부터 결제까지 테스트함)
test파일은 test또는-spec이라는 단어가 붙어있다.
프로젝트 설계 => 깃허브 협업(깃플로우 워크플로우) =>
처음엔 엑셀이나 a4용지를 가지고 api명세서를 짜고 그것을 토대로 erd를 구상한다. -> erd구상을 erd-cloud
과제: 어떠한 api를 만들어야 할지 어떤 포인트를 잡고 만들어야 할지 공부해보자
git branch -> 현재 브렌치를 알려줌
git checkout -b fetchBoard -> 현재 브랜치에서 fetchBoard라는 브랜치로 옮겨줘라 (-b는 없다면 만들어서 옮기라는 뜻이다)
--> 각 기능마다 필요한 기능들은 feature-<기능명> 에서 작업하고 작업이 완료되면 dev라는 브랜치에다 합쳐준다.
--> 기능들이 어느정도 합쳐져 더이상 기능개발이 끝났을때 배포 작업을 위해 release 브랜치에 올린다. (release에서는 기능 추가는 끝나고 버그만 수정한다.)
--> 버그 수정이 완료되면 master 브랜치로 올려 서비스화 한다.
--> 만약 master로 배포하고 서비스 사용중에 중대한 버그가 발견됫을시 hot-fix브랜치로 가져와 버그 수정후 다시 master로 옮겨서 배포한다
git (fork)
-> 메인 브랜치가 있을 경우 개발자들은 메인 브랜치에서 작업하는것이 아니라 복사를 해와서 본인의 워크스페이스에서 작업을 해야한다. 이때 메인 브랜치의 소스코드를 자신의 저장소로 가져오는것을 포크(fork)라고 하고 fork해온것을 Clone하면 사본화 할수있다.
--> 클론하여 작업을 마치면 각 개발자들은 본인의 저장소(레포지토리)에 add commit을 하여 올리고 각 저장소에서 자신들의 코드를 메인 젖장소에 올리기 위해 메인 저장소(레포지토리)에 pull request(PR)을 한다(merge request)라고도 한다.
--> PR을 올리면 메인레포지토리가 각각의 소스코드를 확인하고 PR을 받을지 말지 결정해서 거절할수도 수용할수도있다.
--> 최신화를 위하여 일단 메인 레포지토리에 소스코드들을 pull하고 그다음 작업을 시작하면 된다.
--> git branch -d <브랜치명>: 해당 브랜치를 삭제한다.
--> git push origin <자신이 일하고 있는 branch>
포트폴리오 작성법