Prolog 5기 BE 컨벤션

[java-saeng]

4/26(수) 16시 트랙룸 회의

• 회의 내용 ( 페어당 1개의 의견을 comment로 달아주세요 )
  • 테스트 코드 컨벤션
  • 테스트 코드 리뷰 방식

회의 결과

테스트 코드 컨벤션

1. @DisplayName 을 아래 내용을 포함하여 작성한다.
   • 테스트 조건
   • 테스트 결과
2. @DisplayName 은 @Test 위에 위치한다.

@DisplayName
@Test
void test(){
		...
}

1. 테스트 메서드명을 아래 내용을 포함하여 영어로 작성한다.
   • 프로덕트 코드 메서드명
   • 성공, 실패, 예외 테스트 등의 분류
2. 값이 변하지 않는 변수에는 반드시 final 키워드를 붙힌다.
3. given-when-then 구조를 사용하여 테스트를 작성한다.
4. 모두와 합의되지 않은 Fixture 클래스를 생성하지 않는다.
   • 이유
     • 중복되는 Fixture 가 생길 수 있다.
     • Fixture에 변경이 생길 경우 변경범위가 넓어진다.
5. Nested, ParameterizedTest의 사용은 제한하지 않는다.
6. static 메서드를 가지고 있는 클래스를 사용하여 테스트를 작성할 경우 클래스를 static import 를 사용하여 가독성을 높인다.

import static org.assertj.core.api.Assertions.assertThat;

class Test{
		@DisplayName
		@Test
		void test(){
				assertThat().isEqualTo();
		}
}

1. code style은 PrologJavaStyle.xml 로 지정한다.
2. actions on save 을 항상 아래 항목을 포함하여 설정하여 code style 을 유지한다.
   • reformat code
   • optimize imports

테스트 코드 리뷰 방식

1. 코드 방식 후보
   • 각 페어그룹이 페어그룹 1개의 코드를 리뷰한다.
   • 각 페어그룹이 페어그룹 2개의 코드를 리뷰한다.
   • 1 명이 페어그룹 2개의 코드를 리뷰한다.
2. 코드 리뷰 기한
   • 금요일 4시 전
3. 리뷰 반영 기한
   • 월요일 3시 전까지
4. 리뷰를 남길 때 해당 리뷰를 남긴 근거를 같이 명시해준다.
5. 리뷰 전체 코멘트에 전체적인 리뷰에 대한 요약을 포함하여 작성한다.
6. Reviewers, Assignees를 등록하여 진행한다.
7. 리뷰어의 approve를 받고 작성자가 직접 merge 한다.
8. 전체적으로 코드에서 부족한 부분이나 개선 사항이 보이는 부분을 공유하는 시간을 마련한다. ( 추가 회의 필요 )

브랜치 컨벤션

• 형식 : feature / {issueNumber} - {description}
• 영어는 소문자만 사용한다.

[splitCoding]

테스트 코드 컨벤션 comment 쓰레드

[Cl8D]

🌱 져니 & 스플릿

1. 프로덕션 코드의 분기가 많은 경우 테스트 코드가 상당히 많아질 텐데, 이에 대해 @nested 어노테이션을 사용하는 것이 어떨까요?
2. 만약 하나의 테스트 코드에서 분기가 생길 경우 @ParameterizedTest를 사용하는 것이 어떨까요? (@ParameterizedTest의 인자로 displayname을 필수로 작성하는 걸로)
3. 테스트 코드의 변수에 대해 final로 선언하는 것은 어떨까요?
4. 테스트 코드 내부로 given - when - then 형식을 사용하는 것은 어떤가요?
5. 테스트 코드의 메서드 네이밍은 한글 / 영어로 통일하는 게 좋을 것 같아요. 추가적으로 어떤 행위를 하는지 명시하거나, 아니면 테스트할 메서드의 이름을 작성하는 형식 중 하나를 선택해야 될 것 같습니다.
6. 테스트 코드에서 공통적으로 사용하는 fixture에 대해 별도의 클래스로 분리하는 것이 좋을까요, 아니면 @beforeeach로 초기화를 하는 게 나을까요, 아니면 메서드마다 직접 선언하는 것이 나을까요?

[mcodnjs]

🌊 OCEAN & 🙊 RAON

1. 메서드 네이밍
   • 영어 + (스네이크/카멜 중 선정)
   • prod 코드의 메서드 네이밍을 무조건 동일하게 사용
     -> 단, 여러개의 테스트 메서드가 생성되는 경우는 어떻게 해야될지 모르겠음 (같이 고민해보자)
2. DisplayName
   • 필수 + 한글 작성
   • 상황과 명확한 결과 명시
     • 자동차 이름이 5글자 초과 시 IllegalArgumentException 예외가 발생한다.
     • Car 객체를 반환한다.
     • boolean을 반환한다.
3. @nested, @ParameterizedTest 등을 활용하여 효율적인 코드 작성
4. @test와 @DisplayName 어노테이션 순서 정하기

[wonyongChoi05]

베베, 호이

1. given-when-then 형식 사용 (BDD)
2. 변수 final 선언(immutable)
3. DisplayName 사용 (한글 + 영어)
4. 테스트 메서드 명은 테스트할 메서드 명 (영어)
5. 공통적으로 사용하는 클래스들은 모아두기 (ex: 같은 repository를 사용하는 메서드들이 많음. 따라서 해당 repository들을 모아두고 상속받는 방식 등등..)
6. list 테스트시 extracting 적극 사용
7. void 메서드 테스트시 verify로 테스트
8. 경우의 수가 중복 될 때 @nested 어노테이션을 사용한다.

@Test
@DisplayName("~할 때 ~을 반환해야한다.")
void englishMethod(){
}

@DisplayName("폰은")
class PawnTest {
    @Nested
    @DisplayName("화이트의 경우")
    class case_white {
        @Nested
        @TestInstance(Lifecycle.PER_CLASS)
		  @DisplayName("시작 상태일때")
        class state_init {
            
            @ParameterizedTest(name = "{index} : {0} => {1}")
            @MethodSource("parametersProvider1")
			  @DisplayName("앞으로 1~2칸 또는 대각선으로 갈 수 있다.")
            void move_success() {
                ~~
            }
        @Nested
        @DisplayName("진행 상태일때")
        @TestInstance(Lifecycle.PER_CLASS)
        class state_running {
			  @ParameterizedTest(name = "{index} : {0} => {1}")
            @MethodSource("parametersProvider1")
            @DisplayName("앞으로 1칸 또는 대각선으로 갈 수 있다.")
            void move_success() {
                ~
				}
        }
    }
}

[BGuga]

연어, 푸우

1. @DisplayName으로 테스트 상황에 대한 설명 (

2. Test method 명은 다음과 같은 형식으로 작성하면 어떨까요?

메서드의 유효성_메서드 명_원인

메서드의 유효성 : valid, invalid
메서드 명 : 테스트하고자 하는 메서드
원인 : 어떤 요소가 테스트의 결과를 결정했는지 ( 생략 가능 )

3. given, when, then 사용 ( when, then의 구별이 어렵거나 given 상황이 없다면 expect 사용 )

[eunbii0213]

우르, 주디

1. method 상단에는 @test, @DisplayName(“한글로 테스트 이름 작성“)
2. method 자체 이름은 영어가 좋을 것 같아요
3. 메서드 내부는 given-when-then구조를 사용하는 게 좋을 것 같아요
4. 같은 코드에 여러 분기가 생길경우 @ParameterizedTest를 사용해 테스트하는 것이 좋을 것 같아요!
5. class 최상단에 @DisplayNameGeneration(DisplayNameGenerator.ReplaceUnderscores.class) 붙여서 테스트 이름에 '_'를 ' '로 출력되게 설정하면 좋을 것 같아요
6. static import

[splitCoding]

테스트 코드 리뷰 방식 comment 쓰레드

[mcodnjs]

🌊 OCEAN & 🙊 RAON

12명 -> 페어 6쌍 -> 3쌍씩 2팀
ex) 페어1, 2, 3, 4, 5, 6 => 1팀: 페어 1,2,3 / 2팀: 페어 4,5,6
페어 1: 페어 2, 3 코드리뷰
페어 2: 페어 1, 3 코드리뷰
페어 3: 페어 1, 2 코드리뷰

• 두 팀의 리뷰를 통해서 더 질 좋은 코드 리뷰를 할 수 있을 것 같다.
• 코드 리뷰 기한을 두는 것은 좋으나, 현재 확정된 기간이 없어서 (어떤 주기로 갈지 등) 세부 사항은 정하기 어려움

[mcodnjs]

[추가] 브랜치 컨벤션

• feature/{issue}-{description} 에서 소문자 혹은 - 로만 구성

[wonyongChoi05]

베베, 호이

1. 페어가 6쌍이 나옴. 2쌍씩 3쌍의 코드리뷰 페어들이 나오면 좋겠음(ex: [{페어 1,2}, {페어 3,4}], [{페어 5,6}, {페어 7,8}], [{페어 9,10}, {페어 11,12}]) -> 코드리뷰 페어들이 너무 작은단위로 나오면 한 명당 코드리뷰를 할 수 있는 양과 질이 모두 떨어짐
2. 코드리뷰시 “이렇게 하면 안될 것 같아요“라고만 하지말고 해결 방안 같이 제시하기
3. pr 올린 날로부터 n일 안에 코드리뷰 해주기(주마다 회의니 리팩터링 할 시간도 있어야 함)
4. n주기에 한 번씩은 백엔드 크루들 모두 모여서 전체적인 코드에서 부족한 부분이나 개선 사항이 보이는 부분 공유하기
5. PR 보낼 때 작업 요약해서 설명 달아주기
6. Reviewers, Assignees를 등록해주기

[eunbii0213]

우르, 주디

홍실, 아마란스가 제안해줬던 것 처럼
테스트 코드 리뷰는 각 팀(페어) 끼리 랜덤으로 배정해서 리뷰하는 형식이 좋을 것 같습니다!

[nuyh99]

푸우&연어

1. 페어는 2명씩 지정하는 것이 좋아 보입니다!
2. 페어 하면서 정리된 개념, 개념을 잘 체감 할 수 있었던 부분(ex. dto를 안쓰니 이렇게 되더라)을 정리해서 공유하면 좋겠습니다!

[splitCoding]

테스트 코드 컨벤션

1. @DisplayName 을 아래 내용을 포함하여 작성한다.
   • 테스트 조건
   • 테스트 결과
2. @DisplayName 은 @test 위에 위치한다.

@DisplayName
@Test
void test(){
		...
}

1. 테스트 메서드명을 아래 내용을 포함하여 작성한다.
   • 프로덕트 코드 메서드명
   • 성공, 실패, 예외 테스트 등의 분류
2. 값이 변하지 않는 변수에는 반드시 final 키워드를 붙힌다.
3. given-when-then 구조를 사용하여 테스트를 작성한다.
4. 모두와 합의되지 않은 Fixture 클래스를 생성하지 않는다.
   • 이유
     • 중복되는 Fixture 가 생길 수 있다.
     • Fixture에 변경이 생길 경우 변경범위가 넓어진다.
5. Nested, ParameterizedTest의 사용은 제한하지 않는다.
6. static 메서드를 가지고 있는 클래스를 사용하여 테스트를 작성할 경우 클래스를 static import 를 사용하여 가독성을 높인다.

import static org.assertj.core.api.Assertions.assertThat;

class Test{
		@DisplayName
		@Test
		void test(){
				assertThat().isEqualTo();
		}
}

1. code style은 PrologJavaStyle.xml 로 지정한다.
2. actions on save 을 항상 아래 항목을 포함하여 설정하여 code style 을 유지한다.
   • reformat code
   • optimize imports

테스트 코드 리뷰 방식

1. 코드 방식 후보
   • 각 페어그룹이 페어그룹 1개의 코드를 리뷰한다.
   • 각 페어그룹이 페어그룹 2개의 코드를 리뷰한다.
   • 1 명이 페어그룹 2개의 코드를 리뷰한다.
2. 코드 리뷰 기한
   • 금요일 4시 전
3. 리뷰 반영 기한
   • 월요일 3시 전까지
4. 리뷰를 남길 때 해당 리뷰를 남긴 근거를 같이 명시해준다.
5. 리뷰 전체 코멘트에 전체적인 리뷰에 대한 요약을 포함하여 작성한다.
6. Reviewers, Assignees를 등록하여 진행한다.
7. 리뷰어의 approve를 받고 작성자가 직접 merge 한다.
8. 전체적으로 코드에서 부족한 부분이나 개선 사항이 보이는 부분을 공유하는 시간을 마련한다. ( 추가 회의 필요 )

브랜치 컨벤션

• 형식 : feature / {issueNumber} - {description}
• 영어는 소문자만 사용한다.