회고

Facts(사실, 객관)

• 코드숨 스프링 4주차 완료
• 포큐 알고리듬 실습1 완료
• 포큐 알고리듬 과제1 진행

Feelings(느낌, 주관)

• 알고리듬 공부를 많이 해보지 않아서 어색하다.
• 알고리듬에서 재귀를 많이 사용하는데 제귀를 어떻게 테스트할지 모르겠다.

Findings(배운 점)

• 유연한 테스트 작성의 필요성
• 퀵소드 구현방법

Affirmation(자기 선언)

• 나는 유연한 테스트를 작성하는 개발자이다.
• 나는 문제 해결력이 있는 개발자이다.

05:49 ~ 06:57

Facts(사실, 객관)

• 코드숨 5주차 강좌 수강 및 반영
• 코드리뷰 피드백 반영

Feelings(느낌, 주관)

• 내가 작성한 테스트에 생각보다 중복이 많다.
• 모든 데이터를 비교하는것이 항상 옳은것은 아니다.
  • findById메서드를 테스트하는 코드이다
    • 장황하게 모든 데이터를 비교하는것 보다 id만 비교하고 넘어가는것이 더 효과적이다.

    @Test
@DisplayName("찾은 Product를 리턴한다.")
void it_returns_a_find_product() {
	assertThat(productRepository.findById(id))
    	.matches(output -> output.isPresent())
        .matches(output -> id.equals(output.get().getId()))
        .matches(output -> NAME.equals(output.get().getName()))
	.matches(output -> MAKER.equals(output.get().getMaker()))
	.matches(output -> IMAGE_URL.equals(output.get().getImageUrl()))
	.matches(output -> PRICE.equals(output.get().getPrice()));
}

@Test
@DisplayName("찾은 Product를 리턴한다.")
void it_returns_a_find_product() {
	assertThat(productRepository.findById(id))
    	.matches(output -> output.isPresent())
        .matches(output -> id.equals(output.get().getId()));
}

• 테스트의 의도를 더 명확하게 표현하는 방법을 고민해야겠다.
  • Product 모델의 update(Product source)메서드를 테스트하는 코드이다.
    • 아래의 두 테스트 모두 동일한 결과를 리턴하지만 주어진 product로 업데이트 된다는 사실을 드러내는 정도에는 차이가 있다.

 assertThat(product.update(source))
	.matches(output -> output.getId() == isNull())
	.matches(output -> NAME.equals(output.getName()))
	.matches(output -> MAKER.equals(output.getMaker()))
	.matches(output -> IMAGE_URL.equals(output.getImageUrl()))
	.matches(output -> PRICE.equals(output.getPrice()));

 assertThat(product.update(source))
	.matches(output -> output.getId() == isNull())
	.matches(output -> source.getName().equals(output.getName()))
	.matches(output -> source.getMaker().equals(output.getMaker()))
	.matches(output -> source.getImageUrl().equals(output.getImageUrl()))
	.matches(output -> source.getPrice().equals(output.getPrice()));

Findings(배운 점)

• 당연하지만 테스트에도 DRY원칙이 적용된다.
• 테스트의 의도를 명확히 드러내는 코드를 작성해야한다.

Affirmation(자기 선언)

• 나는 테스트의 의도를 명확히 드러내는 코드를 작성하는 사람이다.
• 나는 DRY원칙을 적용해 개발하는 사람이다.

09:00 ~ 11:50

Facts(사실, 객관)

• pocu 알고리듬 과목 과제 체점 세팅

Feelings(느낌, 주관)

• 생각보다 너무 체점 세팅이 너무 오래걸렸다.
• .gitignore 파일이 없어서 생기는 문제였다.
• 허탈하다
• 결국 pocu 알고리듬 슬랙방에 물어봐서 해결했다.
  • 빌드오류관련 문서가 있었다.

Findings(배운 점)

• 문제가 생기면 우선적으로 공식 문서를 확인해야한다.

Affirmation(자기 선언)

• 나는 문제가 생기면 우선적으로 공식 문서를 확인하는 사람이다.

12:00 ~ 18:30

Facts(사실, 객관)

• 퀵소트 구현
• pocu 알고리듬 과제1 푸는중

Feelings(느낌, 주관)

• 6시간정도 공부를 했는데 생각보다 속도가 안난다.
• 공부를 처음 시작했으므로, 좀더 두고봐야할 것 같다.

Findings(배운 점)

• 퀵소트 작성하는 방법

Affirmation(자기 선언)

• 나는 퀵소트를 작성할 줄 아는 사람이다.