이번주는 7, 8장이다

7장 오류 처리

• 오류 코드보다 예외를 사용하라

  • 함수 호출 즉시 오류를 확인하면 복잡함 → 오류가 발생하면 예외를 던지기

• Try-Catch-Finally 문부터 작성하라

  • try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 하므로 예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다

• 미확인 예외를 사용하라

  • 확인된 예외는 몇가지 장점을 제공하지만 지금은 안정적인 소프트웨어를 제작하는 요소로 확인된 예외가 반드시 필요하지는 않다는 사실이 분명해졌다
  • 확인딘 예외는 OCP를 위반한다 → 최하위 단계에서 최상위 단계까지 연쇄적인 수정이 일어난다

• 예외에 의미를 제공하라

  • 오류 메시지에 정보를 담아 예외와 함께 던진다

• 호출자를 고려해 예외 클래스를 정의하라

  • 외부 API를 사용할 때 감싸기 기법이 최선이다 → 이거 좋은데 KOIN에 적용해볼까...
  • 감싸기 기법을 사용하면 특정 업체가 API를 설계한 방식에 발목 잡히지 않는다

• Null 을 반환하지 마라

  • Null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 ㅂ문제를 떠넘긴다
  • 메서드에서 Null을 반환하고픈 유혹이 든다면 그 대신 예외를 던지거나 특수 사례 객체 반환

• Null 을 전달하지 마라

  • 정상적인 인수로 Null을 기대하는 API가 아니라면 메서드로 Null을 전달하는 코드는 최대한 피한다 → 이런 API가 있나

8장 경계

• 외부 코드 사용하기

  • Map 같은 경계 인터페이스를 여기저기 넘기지 말라
  • 경계 인터페이스를 사용할 때 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의

• 학습 테스트

  • 외부 코드를 사용할 때 간단한 테스트 케이스를 작성해 외부 코드를 익히는 방식

• 학습 테스트는 공짜 이상이다

  • 학습 테스트 열심히 하라는 뜻.

• 아직 존재하지 않는 코드를 사용하기

  • 아는 코드와 모르는 코드를 분리하는 경계
  • 우리가 바라는 인터페이스를 구현하면 우리가 인터페이스를 전적으로 통제한다는 장점이 생김

• 깨끗한 경계

  • 변경이 발생하면 수정이 필요할 수 있다
  • 따라서 경계에 위치하는 코드는 깔끔히 분리
  • 기대치를 정의하는 테스트 케이스도 작성

9장 단위 테스트

• TDD 법칙 세 가지
  1) 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
  2) 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다
  3) 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다

• 깨끗한 테스트 코드 유지하기

  • 지저분한 테스트 코드를 만드나 테스트를 안하나 비슷 → 테스트 코드 리팩토링 하는 상상함
  • 테스트 코드는 실제 코드 못지 않게 중요함
  • 테스트는 유연성, 유지보수성, 재사용성을 제공한다
  • 가독성 을 그렇게 강조한다

• 이중 표준

  • 테스트 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 확실히 다르다

• 테스트 당 assert 하나

  • assert 문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다
  • given-when-then 관례

• 테스트 당 개념 하나

  • 한 메서드 당 하나의 기능처럼 테스트 코드에도 동일하게 하라는 뜻인듯

• FIRST 규칙

  • Fast : 테스트는 빨라야 한다
  • Independent : 각 테스트는 서로 의존하면 안된다 → 이건 진짜 느꼈다.. 테스트끼리 영향을 줘서 힘들었던 경험이 있다
  • Reapeatable : 테스트는 어떤 환경에서도 반복 가능해야 한다
  • Self-Validating : 테스트는 bool 값으로 결과를 내야 한다
  • Timely : 테스트는 적시에 작성해야 한다

끝