2장 입출금 내역 분석기 후반부 내용

결합도

• 한 기능이 다른 클래스에 얼마나 의존하고 있는지를 가늠한다. 결합도는 어떤 클래스를 구현하는데 얼마나 많은 다른 클래스를 참조했는가로 설명할 수 있다.
• 더 많은 클래스를 참조했다면 기능을 변경할 때 그만큼 유연성이 떨어지고, 어떤 클래스의 코드를 수정하게 되면 이 클래스에 의존하는 모든 클래스가 영향을 받게 된다.

비유 예시

시계를 생각해보아라, 시계가 어떻게 동작하는지 몰라도 시간을 알아내는 데 문제가 없다.
사람은 시계 내부 구조에 의존하지 않기 때문이다. 이는 두 가지 임무인 인터페이스와 구현이 서로 결합되지 않았기 때문이다.

코드 예시

public interface BankStatementParser {
    BankTransaction parseFrom(String line);
    List<BankTransaction> parseLinesFrom(List<String> lines);
}

//여기서 BankStatemetnCSVParser는 위에서 정의한 인터페이스를 구현한다.
public class BankStatemetnCSVParser implements BankStatementParser {
    //...
}

결론

• 보통 코드를 구현할 때는 결합도를 낮춰야한다. 이는 코드의 다양한 컴포넌트가 내부와 세부 구현에 의존하지 않아야 함을 의미한다. 반대로 높은 결합도는 무조건 피해야 한다.

테스트

테스트 자동화

• 우리가 코드를 수정했을 때, 지정된 테스트가 빠르게 실행되므로 소프트웨어가 예상하지 못한 문제를 일으키지 않고 제대로 동작할 거라는 확신을 조금 더 가질 수 있다.

테스트 자동화의 장점

1. 확신
   • SW가 규격 사양과 일치하며 동작하는지를 테스트해 고객의 요구 사항을 충족하고 있다는 사실을 더욱 확신 할 수 있다.
2. 변화에도 튼튼함 유지
   • 동료가 코드를 수정했을 때 문제가 발생하지 않을거라는걸 어떻게 확신할 수 있을까?
     자동화된 테스트 스위트가 있다면 바꾼 코드로 인해 새로운 버그가 발생하지 않았음을 확인하는 데 큰 도움이 된다.
3. 프로그램 이해도
   • 테스트 자동화는 소스코드의 프로젝트에서 다양한 컴포넌트가 어떻게 동작하는지 이해하는 데 도움을 준다.

코드 커버리지

• 테스트 집합이 소프트웨어의 소스코드를 얼마나 테스트했는가를 가리키는 척도이다.
  커버리지가 높을수록 예상하지 못한 버그가 발생할 확률이 낮아지므로 되도록 커버리지를 높이는 것을 목표로 삼아야한다.
• 하지만 커버리지가 높다고 해서 우리가 SW를 잘 테스트하고 있음을 의미하는 것은 아니다.
  커버리지는 여러분이 테스트하지 않은 부분이 남아 있음을 알려주는 역할에 지나지 않는다. 테스트품질과는 아무런 상관 없음.