Today I Learned
-
여전히 통제가 안 되는 영역이 있다는 불안감 (레벨 테스트 9일차 작업 회고)Today I Learned 2022. 10. 13. 23:59
어느덧 레벨 테스트 마감까지 하루만을 남겨놓고 있다. 예비군을 다녀와서 작업에 8시간 정도를 덜 쓰기는 했지만, 그건 예비군을 다녀온 다른 동료분도 마찬가지이고, 다른 시간들을 최대한 끌어쓰려 노력했기 때문에 전체 작업에 그렇게까지 큰 영향을 주지는 않았을 것이다. 이제 남은 작업 양의 범위가 상당히 좁혀지기는 했지만, 현재 가장 불안한 점은 남은 작업 영역 중에 내가 완전히 통제하고 있지 못한 것 같다는 생각이 드는 영역들이 남아 있는 것 같다는 부분이다. 동료분들이 이미지를 추가했을 때 성공하던 테스트가 실패하면서 고통받는 모습을 근 며칠 간 쭉 봐 왔다. 마감까지 남은 시간 동안 구현해야 하는 부분 중의 하나가 model이 이미지 주소를 갖게 하고, 그 주소를 받아와 프론트엔드에서 이미지를 불러오도..
-
jest.fn()을 부여한 변수에는 호출 기록이 쌓인다Today I Learned 2022. 10. 12. 23:58
선물하기 페이지 컴포넌트의 테스트를 작성하는 과정에서 모킹한 외부 라이브러리와 직접 만들었던 Store의 함수가 특정 테스트를 수행하는 도중 호출되었는지 검사하는 부분이 있었다. 페이지에서 입력해야 하는 내용을 입력한 뒤, 선물하기 버튼을 누르면 OrderStore를 거쳐 선물한 내역을 백엔드에서 생성하도록 요청하는데, 요청한 결과로 생성된 선물한 내역의 id가 전달되도록 했다. 이때 전달받은 선물한 내역의 id의 존재 유무에 따라 특정 동작을 수행하는지, 하지 않는지를 테스트하고자 했다. 테스트 코드에서 다음과 같이 페이지 컴포넌트에서 사용된 navigate와 fetchUserAmount를 모킹했다. 통과되어야 하는 테스트 코드의 내용은 다음과 같다. 첫 번째 테스트는 통과하는 것을 확인했지만, 두 번..
-
강행돌파는 결국 언젠가 한 번은 해야 한다Today I Learned 2022. 10. 11. 23:59
오후에 홀맨님이 올려주신 미국의 게임 개발자 '존 카맥'이 팟캐스트에서 이야기한 내용을 요약한 글을 보았다. 직접적으로 인용해주신 내용 말고도 흥미로운 내용이 있어 살펴보았다. Q: 어떻게하면 존 카맥 같은 프로그래머가 될수 있나? A: 열심히 하는 수밖에…주당 40시간 일은 파트타임으로 적당. 진지하게 잘 하려면 60시간 이상은 일 해야. 그게 현실이다. 모든 사람이 그렇게 할 필요는 없다. 하지만 훌륭한 걸 만들려면 딴 방법 없다. Q: 어떻게 대단한 것을 만들었나? A: 시스템 레벨의 생각이 중요. 모든 것에 1등일 필요는 없다. 그러나 난 하이 레벨부터 하드웨어까지 스택의 돌아가는 것을 모두 안다. 그럼 전체를 최적화하기 위해 무엇을 희생할지 결정할 수 있다. 새로운 것을 만들려면 이 시스템 레벨..
-
무시무시한 소스코드 중복을 줄이는 메서드화의 힘 (레벨 테스트 6일차 작업 회고)Today I Learned 2022. 10. 10. 23:53
백엔드에서 회원가입 예외처리 로직을 짜는 데 오후 일과 시간을 할애했다. @RequestBody로 전달되는 DTO 데이터들의 상태를 검사해 예외를 처리해줄 수 있을 경우 일차적으로 예외를 발생시키도록 Spring Validation 관련 어노테이션들을 사용했다. DTO에서 @NotBlank와 @Pattern 어노테이션으로 각 데이터가 지정한 유효성에 맞는지 검사하고, 유효하지 않은 결과가 Controller에서 BindingResult의 구현체를 통해 전달되어 오류가 있음이 확인될 경우 오류 메세지를 받아 Exception을 발생시키도록 했다. 테스트에서는 예외에 해당되는 상황이 발생했을 때, 예외를 정상적으로 발생시키는지 테스트를 수행해줘야 했다. 일단은 하나의 테스트 메서드마다 MockMvc를 이용해..
-
성능의 최적화가 오히려 코드 가독성에 좋지 않은 영향을 미칠 수 있다Today I Learned 2022. 10. 9. 23:59
테스트 주도 개발 스터디 3회차에 참여하면서 인상깊게 느꼈던 내용을 정리했다. 다중 통화 로직을 구현하면서 각 환율 간의 변화율을 하나의 쌍으로 갖는 객체 Pair를 정의하고, 해당 Pair 객체의 동등성을 비교하는 테스트 코드를 작성하는 과정이 있다. private class Pair { private String from; private String to; } public boolean equals(Object object) { Pair pair = (Pair) object; return from.equals(pair.from) && to.equals(pair.to); } public int hashCode() { return 0; } 책에서는 hashCode의 값으로 0을 사용할 경우 해시 테이블에..
-
@SpyBean, @MockBeanToday I Learned 2022. 10. 8. 23:59
그동안 Spring 백엔드 애플리케이션을 구현하면서 Controller를 테스트할 때 왜 어떤 상황에서는 @SpyBean을 쓰고 어떤 상황에서는 @MockBean을 쓰는 것인지 구체적으로 알지 못한 채 사용하고 있었다. JpaRepository처럼 실제로 인스턴스를 만들어 사용할 수 없는 것이면 @MockBean을 붙이고, 나머지는 모두 @SpyBean을 붙인 뒤에 테스트하는 건가 보다... 정도의 느낌으로 사용하고 있었는데, 의외의 지점에서 혹시 이건가? 싶은 영감이 들었다. 바로 Jest에서 지원하는 함수 중 하나인 jest.spyOn()을 사용해보면서였다. 다음 소스코드 하단부의 테스트 코드에는 changeReceiverInput 함수가 실행되었을 때 publish 함수가 실제로 실행되었는지를 검증..
-
관심사의 분리를 잘 하면 테스트 코드 작성이 수월해진다 (레벨 테스트 5일차 작업 회고)Today I Learned 2022. 10. 7. 22:23
테스트가 잘 만들어지지 않는 이유는 관심사의 분리가 잘 되지 않아서였다 요 며칠 동안 계속 프론트엔드 테스트 코드에 대한 이야기만 하고 있는 것 같다. 하지만 지금 안 하고 넘어간다 한들 언젠가는 결국 고통받을 것이기 때문에 할 수 있을 때 잘 하고 넘어가고 싶었고, 트레이너님께서 찾아오셨을 때 여쭤봤던 것들도 대부분 프론트엔드 테스트 코드에 대한 내용이었다. 오늘은 트레이너님께서 테스트 코드가 잘 작성되지 않을 때에는 기존 소스코드의 관심사가 분리되어 있지 않을 가능성이 있기 때문에 소스코드의 관심사를 분리해야 할 필요가 있다는 말씀을 해 주셨는데, 인상이 깊게 남아 내용을 정리해보고자 한다. 다음은 상품 목록을 렌더링하는 페이지 내 컴포넌트의 예시 소스코드이다. 최종적으로 구현되어야 할 컴포넌트의 U..
-
문서와 테스트는 어느 정도로 심도있게 작성하는 게 맞는 걸까...? (레벨 테스트 4일차 작업 회고)Today I Learned 2022. 10. 6. 23:55
오늘 구현하려 했던 목표는? 예외처리를 제외한 주문, 주문 내역 로직 구현 (계정 개념을 아직 정의되지 않았으므로 잔액 개념은 우선은 임시로 별도의 Store에서 관리하도록 한 뒤, 추후 계정 개념을 만들 때 이관) 어제 트레이너님께서 알려주셨던 Mocking 재할당 관련 이슈를 자정을 넘기고 다시 수정해서 적용해보려 했는데 적용되지 않는 이슈가 계속 발생했다. 더 이상 매달렸다가는 남은 기간 동안의 컨디션에도 악영향을 미칠 것 같아 잠시 롤백시킨 뒤 새로 구현해야 할 부분들을 우선 구현해보기로 했다. (해당 문제는 오늘 프론트엔드에서 새로 구현한 단위 테스트를 작성하던 중 문제를 해결할 수 있는 경우를 찾아 똑같은 방법으로 적용해볼 수 있을지 시도해보려 한다.) 작업을 하면서 프론트엔드의 동작이나 백엔..