[Week] 5주차 진도

[KimYealynn]

• 발표자를 제외한 인원은 느낀점, 질문사항을 코멘트로 남겨주세요.
• 발표자는 발표자료를 준비하시고 공유해주세요.

이번 주 발표자

• @KimYealynn

진도

• chapter 09. 단위테스트
• chapter 10. 클래스

발표자료

• 단위 테스트
• 클래스

[ChoMk]

9장

TDD 법칙 3가지

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

→ 요지는 테스트 코드와 실제 코드가 비슷하게 성장?해라? 정도로 이해하면 될 듯

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

• 사례를 통하여 대충 만든 테스트 코드는 결국 나중에 버리게 된다는 사실을 말해 준다...
• 가독성, 가독성, 가독성을 높이자...
• 예제를 통하여 느낀 점... 테스트가 테스트를 위한 코드로 남지 않게 큰 맥락에 맞게 추상화층?을 함수로 분리하는 작업을 통하여 가독성을 높이는게 좋은 테스트 코드라는 것을 느낌...
• 시스템 조작 api 위에다 유틸리티를 구현한 후 그 유틸리티를 사용하자(꿀팁인 듯...)
• 스트링과 스트링버퍼 이야기를 하면서 테스트코드에서는 효율을 따질 필요는 없다고 말하고 있다.(흠... 이건 좀..)
• assert 문은 줄이자...
• 테스트 하나에 한 개념을 테스트하자..

FIRST

• fast : 책 초반에서는 성능 보다는 가독성을 높이자 하시지 않았나?... 트레이드 오프이지만... 왔다리 갔다리
• independent : 독립적으로?.. 이미 안드로이드 테스트는 물건너 간 듯...
• repeatable : 언제 어디서나 반복적으로...(윗 단 개발에서는 언제나 지원되는 말?!)
• self - validating : 로그를 읽지 않게 한번에...
• timely : 구현하기 직전에... 작성하자...

10장

클레스 체계

• 순서는 컨벤션과 언어에 따라 다르지만.. 이러한 순서에 맞추면 신문처럼 읽기 편하다
• 테스트를 위하여 내부 어떤함수를 열어야하는 건 최후의 선택으로..

클래스는 작아야 한다.

• 책임을 줄이자. (이름을 짧게...)
• 책임은 하나로 최대한 유지하자...
• 클레스 응집력을 잃으면 쪼개자...

변경으로부터 격리

= 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. 그래서 우리는 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.

[jin5335]

09. 단위 테스트

• TDD(Test Driven Development)
• 내 코드 + 테스트 코드 -> 같이 패키징해서 배포

[DaehunGwak]

요약정리

• 09. 단위 테스트
• 10. 클래스

09. 단위 테스트

실천 전략

• 가독성은 매우 중요!
• Build-Operate-Check 패턴을 이용
• 테스트 함수마다 한 개념만 테스트
• 테스트당 하나의 assert를 지향, 오버 엔지니어링이라 판단될 경우 줄이는 것을 고민

10. 클래스

실천 전략

• 캡슐화를 풀어주는 전략은 언제나 최후의 수단
• 클래스는 작아야함 (SRP, 단일 책임의 원칙)
• 함수를 작게, 매개변수 목록을 짧게
  • 매개변수가 많아지만 인스턴스로 고려
• 몇몇 메서드만 사용하는 인스턴스가 발견하면 책임 분리할 타이밍!
• 작은 클래스가 늘어나 코드가 길어지는 것에 여념치 말자
• DIP, 의존성 역전 원칙을 따라 추상 클래스에 의존적이도록 구현하자

느낀점

얼마전 한 클래스에 mp3 편집도 하고, 옵션 파일도 뽑은것에 반성합니다...

[minSW]

[Chapter 9] 단위 테스트

📖 기억에 남는 부분 & 느낀점

테스트 코드는 실제 코드 못지 않게 중요하다 ... 실제 코드 못지않게 깨끗하게 짜야한다.

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

• 테스트는 유연성, 유지보수성, 재사용성을 제공한다
  • 테스트 커버리지가 높을 수록 잠정적인 버그의 공포가 줄어듬
  • 테스트 케이스가 있으면 변경이 쉬워진다
• 깨끗한 테스트 코드를 만들기 위한 세 가지
  • 가독성, 가독성, 가독성 😧
• 실제 코드보다 테스트 코드에서 가독성이 더 중요(!)
  • 어쨌건 세상 모든 코드가 가독성이 중요...
  • 명료성, 단순성, 풍부한 표현력 + 최소의 표현으로 많은 것을 나타내기
• BUILD-OPERATE-CHECK 패턴

테스트당 Assert 하나

• 단일 assert 문?
  • 좋긴하지만 꼭 지켜야하지는. 최대한 줄이는 건 O
• given-when-then 관례
  • 테스트 코드 읽기가 쉬워짐
  • 그러나 테스트를 분리하면 중복되는 패턴이 많아진다
  • => TEMPLATE METHOD 패턴으로 중복 제거 가능
• 테스트 당 개념 하나

F.I.R.S.T

• 깨끗한 테스트는 다섯가지 규칙을 따른다
• Fast, Independent, Repeatable, Self-Validating, Timely

결론

• 테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화
• 따라서 테스트 코드는 지속적으로 깨끗하게 & 표현력을 높이고 간결하게 관리

[Chapter 10] 클래스

📖 기억에 남는 부분 & 느낀점

코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경을 쓸지라도, 더 차원 높은 단계(클래스) 까지 신경 쓰지 않으면 깨끗한 코드를 얻긴 어렵다.

클래스 체계

• 표준 자바 관례
  • 변수 목록이 맨 처음
  • 정적 공개 상수 (static public)
  • 정적 비공개 변수 (static private)
  • 비공개 인스턴스 변수 (private)
  • 공개 변수 (public) => 필요한 경우 X
  • 공개 함수
  • 비공개 함수는 자신을 호출하는 함수 직후에
• 추상화 단계가 순차적으로 내려가는 구조
  • Like 신문 기사 (=> Chapter. 5)
• 캡슐화
  • 비공개 상태를 유지하기 위해 최선을 다할 것 (풀어주는건 최후의 수단)

클래스는 작아야 한다!

• 함수는 물리적 행 수로 크기를 측정했지만, 클래스는 맡은 책임의 수 센다
  • 만능 클래스?
• 클래스 설명은 if, and, or, but을 사용하지 않고 25단어 내외로 가능해야한다
  • 설명에 해당 단어들이 들어가야한다면 책임이 너무 많다는 증거
• 단일 책임 원칙 (SRP)
  • 단골손님 또 오셨네
  • 클래스나 모듈을 변경할 이유는 단하나 뿐이여야 한다는 원칙
  • 객체 지향 설계에서 중요한 개념이지만 가장 무시하는 규칙 중 하나
  • 돌아가는 소프트웨어 > 깨끗하고 체계적인 소프트웨어 에 초점을 맞춰서
  • 다음 관심사로 전환!!
• 응집도(Cohesion)
  • 클래스는 인스턴스 변수 수가 작아야 함
  • 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 함
  • 메서드가 변수를 더 많이 사용할수록 응집도 ↑
  • but 응집도 높은 클래스는 어려워...
  • 응집도를 유지하면 작은 클래스 여럿이 나온다

변경하기 쉬운 클래스

• 시스템의 결합도를 낮추면 유연성, 재사용성이 높아진다
  • 각 시스템요소가 다른 요소나 변경으로부터 잘 격리되어 있다는 의미 (변경으로부터의 격리)
  • => DIP (Dependency Inversion Principle)을 따르는 클래스
  • 클래스는 상세한 구현이 아닌 추상화에 의존해야 함

느낀점

• 근래에 테스트코드라고는 거의 안짠듯... 🤦🏻‍♀️
  • 로컬 테스트만 잘 진행되면 된다고 생각
  • 죄송합니다.....흑흑
• 깨진 유리창 이론
  • repository 당 test coverage를 강제하는 것도 방법일 듯