테스트 코드 네이밍

실제 운영에 배포를 할 때는 warning 메시지를 보면서 문제의 소지가 있는 것들을 파악해 나가야 한다

이럴 떄 한글 등으로 인한 경고는 불필요한 확인을 하게 된다

@Test 메서드 작성시 한글을 쓰고자할 때는

1. 메서드명에 적고 @SuppressWarnings("NonAsciiCharacters") 처리를 하거나

• 모든 메서드 마다 달기는 그러니.. 클래스 레벨에

1. @DisplayName 을 사용해서 표기하고

• 메서드 명에 영어를 대충 적는다
  • 한글 따로 영어 따로는 체력적인 소모가 나간다..

그외 ..

• 테스트 메서드명에 snake case를 써도 상관 없다

TDD 사이클

Red -> Green -> Refactor

1. Red: 우선 실패하는 테스트를 작성한다

2. Green: 테스트를 통과하는 실제 코드를 최소한으로 구현한다

3. Refactor: 실제 코드를 가다듬는다

최소한의 기능을 구현하는 곳은 Reg -> Green 일 때다 !

커밋을 자주 하는게 좋은가요??

매 요구사항이나 기능 구현마다 커밋을 하는 것은 맞지만..

아주 작은 기능에서 조차 커밋을 나누는것은 생각해보아야 한다..

커밋을 나누는 것은 비용이기 떄문이다

다만 테스트가 깨지는 상태거나.. 컴파일 에러가 나는 상황에서는 커밋하면 안됀다!

private method 테스트

• 정말로 필요한 테스트인지 고민을 한다.

  • 오죽하면 이런 사이트도 있다.. should i test private method ? : NO

• 만일 접근제어자를 수정할 정도로 필요한 테스트이면 수정한다

• default 접근제어자를 적절히 활용하여 테스트한다

  • 접근제어자를 생략하면 된다

• 운영 코드에 손상이 가지 않게 메서드를 카피해서 테스트한다

• 해당 private 메서드를 호출하는 public 메서드를 통해 간접적으로 테스트한다

• 리플렉션은 비추한다

한번에 구현하기 어려운 코드는

테스트 메서드에 순차적으로 구현한 뒤에 실제 구현 코드로 이동시킨다 !

한 테스트 메소드에서 assert 문을 여러개 사용하는것은 좋지 않은 방법인가요?

BE_후디님 질문

테스트 코드를 assertThat 문.. 여러개 작성하는 것은 좋지 않다..

1. 하나의 assertThat으로 인해 그 다음의 assertThat이 수행되지 않을 수 있다

2. 해당 메서드에서 검증을 해야하는 것이 여러가지 일을 하지 않나 생각을 해보아야 한다

Equals, HashCode를 꼭 정의해야 하나요?

Equals, HashCode, ToString 등은 객체임을 잘 나타내는 메서드이기 떄문에

(강사님은) 굳이 사용하지 않더라도 미리 만들어 놓고 사용하는 것을 선호하신다 !

(크루분이 정리해주셨다 !) 강타입 언어 ??

means that the type of a value doesn’t change in unexpected ways.

예를들어

자바는 정적타입 강타입 언어이다.

파이썬은 동적타입 강타입 언어이다.

JS는 동적타입 약타입 언어이다.