온보딩 1주차

2/8

동작 확인을 위해 테스트
메서드를 테스트할 때 잘못된 로직의 메서드는 어떻게 검증할까? -> 실패하는 테스트 먼저 만들기
테스트를 만들기 전에 검증하고자 하는 메서드가 어떤 기능인지, 어떤 상황에서 문제가 될 수 있을지를 고민해본다. 경계값을 잘 찾아본다.
경계값 찾기 : 내가 검증하고자 하는 값의 끝단을 찾는다.
단위 테스트가 있다고 모든 경우를 테스트할 수 있는 것도 아니다. 어느 선까지 테스트를 할 것인지 기준을 정해보자.
나의 테스트 기준 : 내가 처한 상황에서 구문이 제대로 동작한다는 확신이 들 때까지!
내가 단위 테스트를 작성하는 이유 : 여러 가지 케이스를 편리하게 실행시킬 수 있어서
내가 작성한 좋은 단위 테스트는 어떤 부분에서 좋은 단위 테스트였을까? : 여러 가지 테스트 케이스를 생각해볼 수 있고, 빼놓은 케이스가 있는지 확인해볼 수 있었다.
좋은 단위 테스트를 작성하기 위해 어떠한 시도를 해볼 수 있는가? : 단위 테스트의 단위, 로직 검증은 어떻게 할 수 있을지, 읽기 쉬운 코드인지, 경계값이 포함된 케이스가 있는지 확인하기. 로직이 좋은 코드로 되어 있어서 테스트 코드를 작성하기 쉬운가?
private 메서드의 코드는 어떻게 테스트할 수 있을까?

코드는 잘 동작해야 한다. 코드에 매몰되어 놓치지 않아야 한다.
코드는 읽기 쉬워야 한다. 의도를 드러내고 유지보수하기 좋은 것은 매우 중요하다. 미래의 나를 위해 예쁘게 짜자.
코드는 보기 좋아야 한다. 심미성의 부분. 컨벤션이나 들여쓰기, 줄바꿈 등인 듯하다.
코드는 관리하기 쉬워야 한다. 아무리 잘 작성해도 예상과 다르게 동작할 수 있다. 개발 이후가 가장 중요하고, 2,3차 사용자들이 관여하는 점에서 매우 중요한 항목이다. 계속 유지보수 되어야 한다.
코드는 테스트 가능해야 한다. 자동화 테스트가 가능해야 하고, 설계 의도에 맞게 올바르게 동작하는지 확인한다.
코드는 변경하기 쉬워야 한다. 기능의 변경, 확장, 재사용은 매우 빈번하다. 최소한의 노력으로 변경 가능해야 하며, 부작용은 최소화해야 한다.
코드는 효율적으로 동작해야 한다. 코드의 동작이 아닌 산업적인 관점에서 효율적인 것이 중요하다. 최소의 개발 리소스를 투입하여 결과물이 나올 수 있어야 한다. (인적 리소스 포함)
좋은 코드는 한 순간에 만들어지지 않는다.

요구 사항은 따로 정하지는 않았는데, 이런 식으로 객체의 역할을 분리해보는 방식도 좋은 것 같다.