또라이개발자

Prisma의 주요 단점 중 하나는 JOIN 절이 지원되지 않았던 것이었다. 이 문제는 최근 5.7 버젼에서 FeaturePreview로 추가되었고, 이 소식을 듣고 반가운 마음에 즉시 적용을 시작했다. 이렇게 고민 없이 적용할 수 있는 이유는 바로 테스트에 있다. 일반적으로 대부분은 주요 라이브러리의 버전 업데이트를 하지 않거나, 할 경우에도 매우 보수적으로 진행하는 경향이 있다. 그럼 어떻게 진행했는지 진행과정을 공유해 보겠다. 1. 패키지 업데이트 & 전체 테스트 수행 패키지 매니져를 통해서 업데이트를 하고 모든 테스트를 수행했지만, 실패하는 테스트 케이스는 없었다. 일단은 안심이다. 아직 추가된 Feature를 사용하지 않아서 쉽게 성공했을 수도 있다. 2. 기능 리팩토링 이제 가장 중요한 Rep..

최근에 작성한 테스트 관련 글이 조회수가 상당히 높았다. 그러나 처음부터 테스트 코드를 잘 작성했던 것은 아니었다. 이번 기회에 과거를 돌아보며 어떻게 공부했는지 나누고자 한다. 나도 'TDD by Example'이라는 책을 통해 테스트와 처음 만났다. 회사에서 진행한 스터디에 참여하며 테스트에 대한 이해를 높였다. 테스트가 프로그램의 스펙이라는 개념은 새롭게 다가왔다. Java에서는 Junit과 Test 키워드에 익숙했지만, Ruby나 다른 언어 및 테스트 프레임워크에서는 'Spec'을 사용하는 것도 흥미로웠다. 또한, 테스트 코드에 능숙한 동료가 복잡한 부가세 계산을 위한 테스트 케이스를 작성하며 그 실행 과정을 보여주었는데, 이는 매우 인상 깊었다. 당시 CTO께서는 빠른 피드백을 통해 즐거운 개발..

사진: Unsplash의Ferenc Almasi 얼마 전 모임에서 만난 후배 개발자가 면접 경험을 공유했다. '면접관이 테스트 코드 작성 여부를 물었다'라고 했다. 나 역시 면접에서 이를 중요하게 여긴다. 면접에서 나는 테스트 코드 작성의 이유를 반드시 질문한다. 단순히 테스트를 어떻게 작성에 대한 하드스킬에 대한 질문의 의도가 아니다. 테스트를 정말 작성을 한다면 경험을 기반으로 한 필요성에 대해서 설명할 수 있다고 생각하기 때문이다. 실제 업무에서 테스트코드 작성을 하게 된다면 업무 생상성뿐만이 아니라 좋은 코드 설계도 가능하다고 생각하기 때문이다. 왜 그렇게 생각하는지를 좀 정리를 해보려고 한다. 첫 번째 이유는 빠른 피드백이다. 예를 들어 회원가입 API를 만드는 Task 가 있다고 하자. 이메일..