워밍업 클럽 3기 BE 클린코드&테스트 - 2주차 발자국

2주차 회고

다음주부터 리팩토링 프로젝트를 시작한다.

일단 소스 코드를 보고 이해해야 하는 상황인데, 테스트 코드를 중심으로 살펴보면 좋을 것 같다.

테스트 코드에 녹여진 내용을 보고 의도와 기능을 파악해 볼 예정이다.

만약 의도가 잘 나타나지 않는다? 리팩토링 포인트라고 생각하고 해당 부분을 개선해보자.

읽기 좋은 코드 강의에서 보았던 역할과 책임 등등의 이론도 적용해보는 좋은 실습 대상으로 생각해보자.

일찍 일어나고, 집중력 있는 하루를 보내자.

지금 이 순간이 좋은 추억으로 남으려면, 후회하지 않으려면 열심히 해야 한다.

긍정적으로 생각하고, 다른 사람들을 포용할 수 있는 심적 여유를 가지는 일주일이 됐으면 한다.

할 수 있다. 힘내자. 웃자.

테스트 코드 작성을 소홀히했다.

기간 내에 기능을 구현하기 위해 테스트 코드는 제쳐두고 주먹구구식으로 개발하기에 급급했으나,

결국 문제점이 발견되어 다시 돌아와 예외처리를 하고 기능을 수정하는 일이빈번했다.

결국 테스트 케이스를 제대로 작성하는 것이 가장 빠른 길이다.

테스트를 통해 버그를 발견할 수 있고, 기능 변경에 따른 영향도 파악이 가능하며,

테스트의 의도를 분명히 함으로써 팀원들 간 생각을 공유할 수 있는 매개체가 된다.

가까이 보면 느리지만, 멀리 보면 가장 빠르다.

테스트는 귀찮지만 해야한다. 잊지말자.

해피 케이스와 예외 케이스 모두 작성해야 한다.

특히 경계값이 있는 조건에 대한 테스트 작성이 중요하다.

테스트하기 어려운 영역, 제약조건이 있어 테스트 진행이 어려운 경우, 테스트를 수행할 때 마다 값이 변경되는 경우.

외부에서 원하는 값을 주입 가능하도록 변경한다.

만약, 테스트가 어려운 메서드라고 생각되는 경우 메서드 설계를 변경해보자.

기능 주도로 개발하다보면 위와 같은 상황을 자주 마주할 수 있다.

실패하는 테스트 작성, 초록불을 보기 위한 최소한의 코딩, 리팩토링

내가 작성한 코드에 대해 자주, 빠르게 피드백을 받을 수 있음.

선 기능 구현, 후 테스트 작성의 단점

테스트 자체를 누락(귀찮고 테스트하기 힘들어~), 특정 해피 케이스만 작성, 잘못된 구현 등등..

위와 같은 단점을 극복할 수 있다.

테스트를 어떻게 할지 고민함으로써 복잡도가 낮은 유연한 코드를 작성할 수 있게 되고,

즉시 피드백을 받을 수 있다.

테스트 주도 개발 방식을 통해 어떤 식으로 효율적으로 테스트할 수 있을지, 테스트 설계 단계부터 고민해보자.

TDD가 만능은 아니지만? 이를 판단하기 위해선 TDD를 극한까지 사용해보아야 한다.

테스트 코드는 프로덕션 기능을 설명하는 가장 좋은 문서다.

개발에서의 고민점들을 테스트 코드에 녹여놓았기에 어떤 고민의 결과물을 팀 간 공유할 수 있다.

특정 기능의 역할을 파악하기도 쉬울 듯 하다.

디스플레이 이름을 섬세하게 작성하자.

~테스트 라고 작성하지 말고..문장 형태로 행위와 결과를 기술하기.

given, when ,then 으로 분리, 시나리오에 기반한 테스트케이스 작성.