TDD - 테스트 주도 개발 part.2

테스트 주도 개발 3부

전반적으로 테스트 주도 개발에서 사용되는 것들에 대한 비교적 상세한 설명들이 적혀있다. 모의 객체(mock)라던가, 단언(assertion) 이라던가. 개인적으로 궁금했던 서드파티 API를 사용해야 할 때, 데이터베이스 조회가 필요할 때 등에 대한 설명도 적혀 있어 갈증도 해소됐다.

책을 통해 해소된 것도 있지만, 사실 책을 읽었어야 했을까라는 생각도 든다. red-green-refactoring 루틴에 대해 설명은 좋았으나 거기까지만 와닿았다. 이해를 위한 예제들은 다소 지루했으며 패턴 설명에선 오히려 예제가 부족하다 생각했다.

사람은 보고 싶은 것만 보기 때문일까, 기억에 남는 건 좋은 의자를 사야 한다는 것(?)과 코딩이 막힐 땐 샤워를 하라(?)이다. 하지만 이렇게 끝낼 순 없기에 TDD 기반의 사이드 프로젝트를 진행하려고 한다.

테스트코드 컨벤션

테스트 주도 개발 3부를 읽으며 test{테스트할_기능}으로 네이밍 하는게 썩- 맘에 들지 않았다. 그래서 찾아보니 여러 컨벤션이 있다. (참고:Dzone-7-popular-unit-test-naming)

1. 메서드명_테스트상태_기대결과
2. 메서드명_기대결과_테스트상태
3. test테스트할_기능
4. 테스트할_기능
5. should_기대결과_When_테스트상태
6. when_테스트상태_Expect_기대결과
7. given_사전조건_When_테스트상태_Expect_기대결과

위와 같이 7개 컨밴션이 있는데 5,6,7번이 함수명만 봐도 무엇을 테스트하고 싶은건지 바로 이해 가능해 보여 좋아 보인다. 테스트할 메서드는 주석으로 식별 가능하게 하면 되니까.

TDD with 페어 프로그래밍

페어 프로그래밍은 이혜영(a.k.a OREZ)님과 함께합니다.🙇🏻‍♂️ 원래는 시간 제한을 두고 번갈아 가며 Driver, Navigator를 해야 하지만 TDD가 손에, 머리에 익을 때까지는 제한을 두기보단 각자 해보고 싶은 만큼 해봤을 때 교대하려고 한다. 대신 철저하게 쉴 땐 쉰다! 시작부터 퍼지지 않기 위해 비교적 쉬운 주제와 서로 편한 언어로 하려고 한다.

TDD를 적용할 사이드 프로젝트

어떤 걸로 테스트 코드를 입문해 볼까 고민을 해보다가 orez님이 기존에 진행하시던 채식주의자를 위한 웹 서비스(EasyVeggy) 사이드 프로젝트에 조인하기로 했다. 이유는 아래와 같다.

1. 취지가 좋음.
2. 방치됐던 프로젝트라 작성된 코드가 적음.
3. JPA, 더 나아가 ORM을 좀 더 제대로 써 볼 수 있는 기회라고 생각됨.
4. front-end는 React라 따라가기 쉬움.
5. 배포까지 한다고 가정할 때, 얼마 전 AWS 공부했던걸 써먹기 좋을 것 같음.

그럼 화이팅👍