진행 기간
2023.02.14 - 2023.02.27 (14일간)
미션 내용
1단계 사다리 생성
2단계 사다리 게임 실행
리뷰 정리
step1 리뷰
- 객체 생성이 성공적으로 이루어졌는지를 확인하는 테스트 코드를 작성할 때
예외가 던져지지 않는 것을 체크하는 것보다는, 값들이 제대로 들어갔는지에 대해 확인.
또는 equals&hashcode를 통해 원하는 객체가 제대로 만들어졌는지를 확인. - 의미없는 @ParameterizedTest
테스트 파라미터는 최대한 많을수록 좋다고 생각했었는데, 의미없는 값들까지 테스트하게 되면
나중에 코드의 양이 많아졌을 때 의미없는 파라미터까지 도느라 테스트에 걸리는 시간이 늘어난다.
-> 테스트의 목적에 따라 필요한 만큼의 파라미터만 테스트 (경계값 위주) - 커밋 규칙
커밋 로그 작성 규칙, 커밋 시점 등을 제대로 정하자 - 도메인에 대한 확실한 명칭
문서화 할 때 도메인에 대한 확실한 명칭을 정하고 시작하자
step2 리뷰
- 랜덤값을 테스트하기 위해서는
랜덤값이 필요한 메소드(또는 생성자)의 인자로 생성된 랜덤값을 주입 or 원하는 generator 주입 - 검증 위치
view에서의 검증 & domain에서의 검증 - Optional로 반환되는경우 get()을 사용하기보다는 orElse() 혹은 orElseThrow() 사용
추가 리뷰 (by 허브)
- 상수와 필드 사이 빈칸으로 구분
- \n의 경우 OS마다 다르게 동작할 수 있다 -> System.lineSeparator() 사용
고민
리뷰어님과 랜덤값 테스트에 대한 이야기를 나눴다.
나는 자유자재로 테스트하기 위해 BooleanGenerator 인터페이스를 상속받은 TestGenerator를 만들어 테스트코드에서 사용했다 (전략패턴).
(Ladder의 생성자 인자로는 사다리 높이와 가로 너비만 받아서 빈 사다리를 만들어두고, generate 메소드를 통해 실제 사다리를 만드는 방식)
하지만 리뷰어님께서 테스트를 위한 Generator를 만들어서 테스트 코드를 작성한다면 이 코드를 백프로 신뢰할 수는 없을 것 같습니다!라는 리뷰와 함께 하단의 방법을 제시해주셨다.
하지만 이 방법으로 하게 되면 production 코드를 생각해봤을 때 Line의 외부에서 Bridge들을 만들어 넣어주고, Ladder의 외부에서 Line들을 만들어 넣어줘야 하는데, 그럼 Line과 Ladder의 자율성이 손상된다고 생각한다. 스스로 generate하는게 아니고 외부에서 generate한 결과물들을 단순히 넣어주는 느낌이니까..!
하지만 이 방법으로 하게 되면 새로운 generator를 만들 필요 없이 테스트를 진행할 수 있다는 점에서 좋은 것 같다.
결국 나는 기존 방법을 택했지만,테스트를 위한 Generator를 만들어서 테스트 코드를 작성한다면 이 코드를 백프로 신뢰할 수는 없을 것 같습니다! 라는 리뷰도 납득이 되어서 여전히 고민인 상태이다 .. 쩝 무엇이 맞을까??
후기
- 미션오픈 전전날부터 몸이 급격히 안 좋아졌는데(감기+결막염), 병원투어를 다녔는데도 불구하고 2주동안이나 아팠다.. 그래서인지 이번 미션 내내 몽롱하게 있었던 것 같아서 아쉽다.
- 나의 두번째 페어인 바론을 보며 많은걸 배웠다. 나는 지금까지 무언가를 해내고 싶으면 시간을 갈아서 해내는 편이었는데, 바론은 딱 정해진 시간을 밀도 있게 사용한다. 늘어지거나 우유부단한 시간 없이 빠르게 탁탁탁 치고 나간다. 나도 앞으로는 무작정 시간을 투자하지 않고, 정해진 시간동안 속도감있게 진행해서 할일을 마치고자 노력해야겠다.
- 우테코에서 제시한 이번 미션의 목표는 TDD였는데, 솔직히 말하자면 어느순간부터 TDD와 기존의 방식(프로덕션 먼저 구현)이 섞인 것 같아서 아쉽다. TDD는 너무 어렵다..
오잉이라네 오잉이라네 오잉이라네 ~