이번주 학습 내용

테스트를 작성을 위해 생각하는 요령과 테스트를 왜 필요한지 등 테스트에 관해서 학습했다.

테스트 작성을 위해 고민 해나가는 과정

새로운 요구사항이 들어왔을 때, 요구사항이 잘 정의 되었는지, 암묵적으로 이야기 되지 않은 내용이 있거나, 아직 고려하지 못한 예외상황에 대한 처리가 필요할지 확인을 해야한다.
테스트 케이스들을 세분화 해서, 해피 케이스 말고도, 예외 케이스인 경우도, 개발자가 예상한 상황이 되는지 체크할 수 있다.
예외 케이스의 경우, 경계값 (범위나 구간, 날짜 등)으로 체크를 하는 것이 좋다.

TDD 방식

코드 구현이전, 테스트를 작성 후, 구현을 통해 테스트가 구현과정을 주도로 하는 방법

TDD 방식은 다음과 같은 과정을 거친다

RED 실패하는 테스트 작성

GREEN 테스트 통과를 위한 최소 작업

REFACTOR 구현 코드 개선 하며, 테스트 통과를 유지하도록 한다.

장점

테스트를 먼저 작성한 뒤, 구현을 하게 된다면, 테스트하기 어려운 영역(관측할 떄마다 다른 값에 의존을 하거나, 외부 세계에 영향을 주는 코드)들에 대해서 외부 파라미터 등으로 넘겨주도록 해, 해당 부분도 테스트 가능한 코드를 작성할 수 있다.
내가 작성하는 코드에 대해서, 자주, 빠르게 피드백 받을 수 있게된다. (테스트 케이스 확인만으로 가능)
구현 후 테스트를 작성하게 되면, 구현부에 의존한 테스트에 대해서만 생각하게 될 수 있어, 놓치기 쉬운 엣지 케이스들에 대해서도 고려할 수 있게 된다.
테스트를 통해 보장해야할 기능목록이 생성 되 있어, 과감한 리팩토링도 가능하게 된다.

BDD 방식

개발자가 아닌 사람이 봐도 이해할 수 있을만한 추상화 수준을 테스트에 적용하는 것

함수 단위의 테스트 보다 시나리오에 기반한 테스트케이스 자체에 집중하여 테스트 한다.

Given / When / Then

Given : 시나리오 진행에 필요한 모든 준비 과정

When : 시나리오 행동 진행

Then : 시나리오 진행에 따른 결과 명시, 검증

BDD방식으로 테스트를 작성 한다면, 테스트 코드로 프로덕션의 기능을 명시하는 문서의 역할을 할 수 있다.

해당 방식으로 작성된 테스트를 보고, 코드를 이해하는 다양한 시각과 관점을 키워갈 수 있고, 팀단위로 관리된 테스트 들은 다른 사람들이 어떤 관점으로 테스트를 작성했는지를 통해 팀의 자산으로 관리될 수 있다.

좋았던점 (Liked)

테스트 코드를 좀더 알아가고 싶어서 깃에 스프링 부트 소스등 잘 만들어진 테스트 코드가 무엇이 있는지 찾아보는 시간을 가졌다.

아쉬웠던 점 (Lacked)

이번주에 회사 회식과, 타 일정이 많아 미션에 쏟은 시간도 짧았고, 이번주에는 강의도 많이 밀렸다..

내가 저번주에 2주만에 완강을 하면서 끝난듯이 너무 쉬는 시간이 많았던것 같다.

다시 마음을 다잡고 완강할 수 있도록 해야겠다.

배운 점 (Learned)

이전에, 테스트 코드를 TDD 방식으로 작성해보고자 했었던 적이 있었는데, 그때는 TDD의 장점에 대해서 전혀 파악하지 못하고, 어떻게 사고해야 하는지, 테스트가 진짜 의미는 있는걸까 하는 의문점이 지금은 조금씩 해결되 가고 있는 느낌이다. 강의를 잘 쫓아가며, 테스트에 대해 더 빠져보아야 겠다.

앞으로 바라는 점(Longed for)

일단 이번주에 진행하지 못한 부분이 커서.. 진도에 맞추어 진행할 수 있도록 열심히 쫓아가야겠다!