기테스트 GiTest

테스트 별 코드 커버리지

깃 체인지 트래킹

이 두가지를 섞으면 체인지에 해당하는 테스트를 추려낼 수 있고, 그것만 돌리면 커밋당 최소 테스트를 돌릴 수 있다.

만약 이 형태를 로컬에서 돌릴 수 있으면 정말 최강의 스트레스 없는 TDD가 가능 할 것 같은데, 일단 이것저것 제한은 있다.

일차적으로는 이걸 서버쪽, 젠킨스쪽에서 돌리는 건 충분히 가능한게, 젠킨스는 일단 완전한 브랜치 커밋 기반 빌드가 보장되고, 기존 빌드에 대한 기록 저장도 로컬보다 유용하기 때문.

일단 저런 형태의 젠킨스 익스텐션 툴을 만들고, 그 다음 단계가 이걸 로컬로 끌어내리기를 하는게 좋을 듯

1. 현 커밋의 모든 테스트들을 뽑아내고

2 그 개별적인 테스트들을 각각 돌려서 개별 코드 커버리지를 뽑아내고

3 그걸 코드 라인별 어떤 테스트 커버가 있는지 자료를 만들고

4깃 체인지 로그에따라 관련된 테스트가 어떤게 있는지 찾아내는 것

5중간에 어떤 테스트가 추가되었는지 알아낼 수 있나?

동작순서
1 로컬개발 유닛 테스트
2 커밋과 푸쉬
3 젠킨스 빌드 및 라인별 테스트 결과에 대한 커밋
4 로컬 풀 (젠킨스 테스트 결과를 가지고 옴)
5 로컬 유닛테스트는 젠킨스의 테스트 결과를 기반 diff test
스케일러블 테스팅
디프 테스팅
오토 스윗 테스팅
테스트 스윗 옵티마이제이션
프리사이즈 스윗 ㅋㅋㅋ 프리사이즈 슈트 ㅋㅋㅋㅋ

투두

• 1 젠킨스 설치
  
• 2 젠킨스 빌드 설정
  
• 3 젠캔스 유닛테스트 설정
  
• 4 젠킨스 테스트 리스트를 가져오기
• 5 테스트 리스트에 따른 개별적인 테스트 실행
• 6 테스트 결과 가져오기
• 7 테스트 결과들을 머지/ 라인별 테스트 목록 작성
• 여기가 가장 힘든 부분.
• 라인별 테스트 목록을 어떤 형태로 만드는게 좋으려나 자료구조?
• 8 생성된 테스트 결과를 커밋하기파일 구조를 어떻게 가져갈 지에 대해 고민해 봐야 함
• 루트 디렉토리에서 분기된 숨은 폴더
• 각 디렉토리+파일별 매핑을 따로 해야 하려나
• 9 diff test
  
• 현제 체인지 로그와 저장된 라인별 테스트 커버에 따라 테스트
•