phantasmicmeans 기술 블로그

3.1 단위 테스트 구성 방법 AAA 패턴 사용 우리가 흔히 사용하는 give/when/then 과 동일하고, 모든 테스트가 단순하고 균일한 구조를 갖는 데 도움이 된다. 준비 구절: SUT 와 해당 의존성을 원하는 상태로 만듬 실행 구절: SUT 메소드 호출 및 준비된 의존성 전달 검증 구절: 결과 검증 (반환 값이나 협력자의 최종 상태, SUT 가 협력자에 호출한 메소드 등으로 표시) 여러개의 준비, 실행, 검증 구절을 피하라 여러 개의 준비, 실행, 검증 구절은 테스트가 너무 많은 것을 한 번에 검증한다는 의미이다. 각 동작을 고유의 테스트로 나눠라 통합테스트의 범주 - 통테에서는 속도를 높이기 위해 이렇게 해도 괜찮다. 테스트 내 if 문 피해라 if 문은 테스트가 한 번에 너무 많은 것을 표시 ..

업무로 프리미엄 컨텐츠 허브 서버개발을 진행하며, 작은 스펙이지만 기억에 남았던 내용이 있어서 가볍게 공유 드리고자 합니다. mongodb를 사용하고 있기에 이전 글/다음 글은 아래 용어와 동일하게 이해해주시면 됩니다. 이전 글 == lte(less than equal), lt(less than) 다음 글 == gte(greater than equal), gt(greator than) 스펙 설명 컨텐츠 엔드 아래 사진처럼 각 컨텐츠 엔드 하단에는 동일 카테고리의 컨텐츠 목록을 노출하는 영역이 존재하구요. 노출 세부 스펙은 아래와 같습니다. 현재 컨텐츠는 가운데로 두고 앞(다음 글) 뒤(이전 글)의 컨텐츠 노출 총 N개 노출 e.g.) 5개 노출인 경우 -> 다음 글 2개 / 현재 컨텐츠 / 이전 글 2개..

약 1년간 이곳저곳에 약 500건의 unit test (+ 약간의 통합 테스트)를 작성했습니다. 테스트에 대한 깊은 지식은 아직도 없고.. 아래 정도에 도달한 것 같습니다. 이제 유닛 테스트를 어떻게 작성해야 하는지 알겠다. 직접 겪어보니 왜 작성해야 하는지 이해가 된다. 왜 테스트 작성이 어려운지 알겠다. 현재의 제가 지금까지 테스트를 작성해오며 느꼈던 점 / 생각했던 것들을 적어봤습니다. 이 생각들은 앞으로도 계속 변할 수 있을 것 같기도 해서 몇 년 후 재밌게 읽어볼 수 있을 것 같습니다. 목차는 아래와 같습니다. 1. 계층 짬뽕 지름길을 피해 보자 2. Spring Data Repository 너 이놈 .. 3. 넓은 의미의 서비스 4. 테스트가 없는 프로젝트에 신규 테스트 작성은? 5. 현재보다..

시스템이 세 가지 컴포넌트(UI, 업무 규칙, 데이터베이스)로만 구성된다고 생각하기 쉽다. 몇몇 단순한 시스템에서는 이 정도로 충분하다. 하지만 대다수의 시스템 컴포넌트의 개수는 이보다 훨씬 많다. 움퍼스 사냥 게임 GO EAST, SHOOT WEST와 같은 단순한 명령어를 사용한다. 플레이어는 명령어를 입력하며, 컴퓨터는 플레이어가 보고 듣고 경험한 것들로 응답한다. 텍스트 기반 UI는 유지하되, 게임 규칙과 UI를 분리해서 제품을 여러 시장에서 다양한 언어로 발매한다고 가정해보자. 이 규칙은 언어 독립적인 API로 UI 컴포넌트와 통신할 것이고 UI는 API를 사람이 이해할 수 있는 언어로 변환할 것이다. 소스 코드 의존성을 적절히 관리하면 어떤 언어를 UI가 사용하더라도 게임 규칙을 재사용 할 수 ..

아키텍처 경계를 완벽하게 만드는 데는 상당한 비용이 든다. 쌍방향의 다형적 Boundary 인터페이스, Input과 Output을 위한 데이터 구조를 만들어야 할 뿐만 아니라, 두 영역을 독립적으로 컴파일하고 배포할 수 있는 컴포넌트로 격리하는데 필요한 모든 의존성을 관리해야함. 이렇게 만들려면 엄청난 노력이 필요함. 애자일 커뮤니티에서의 많은 이가 이러한 종류의 선행적 설계를 탐탁치 않게 여김 YAGNI(You Aren't Going to Need IT) 원칙을 위배하기 때문. 하지만 아키텍트라면 이 문제를 검토하면서 "어쩌면 필요할 지도" 라는 생각이 들 수 있다. 그렇다면 부분적 경계(partial boundary)를 구현해볼 수 있다. 마지막 단계를 건너뛰기 독립적으로 컴파일하고 배포할 수 있는 ..