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)를 구현해볼 수 있다. 마지막 단계를 건너뛰기 독립적으로 컴파일하고 배포할 수 있는 ..

프레젠터는 험블 객체 패턴을 따른 형태로, 아키텍처 경계를 식별하고 보호하는 데 도움이 된다. 22장 '클린 아키텍처'는 험블 객체 구현체들로 가득 차 있다. 험블 객체 패턴 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 분리하기 쉽게 가장 기본적인 본질은 남기고, 테스트하기 어려운 객체를 험블 객체로 옮김. 나머지 모듈에는 험블 객체에 속하지 않는, 테스트하기 쉬운 행위를 모두 옮긴다. GUI의 경우 단위 테스트가 어려움 화면을 보면서 각 요소가 필요한 위치에 적절히 표시 되었는지 검사하는 테스트는 작성하기 매우 어렵다. 하지만 GUI에서 수행하는 행위의 대다수는 쉽게 테스트할 수 있다. 험블 객체 패턴을 사용하면 두 부류의 행위를 분리해 프레젠터와 뷰 라는 서로 다른 클래스로 만들 수 있다. 프레젠..

ADP: 의존성 비순환 원칙 하향식(top-down) 설계 SDP & SAP ADP: 의존성 비순환 원칙 컴포넌트 의존성 그래프에 순환(cycle)이 있어서는 안된다 숙취 증후군 동일한 소스 파일을 수정하는 환경에서 발생. 누군가가 마지막으로 수정한 코드 때문에 정상 동작하지 않음 주 단위 빌드(Weekly build) 한 주의 첫 4일은 알아서 코딩하고 마지막 날 몰아서 통합 결국 통합 이슈를 겪게 되고 효율성 저하 순환 의존성 제거하기 개발 환경을 릴리즈 가능한 컴포넌트 단위로 분리하는 것 개발자가 해당 컴포넌트가 동작하도록 만든 후, 해당 컴포넌트를 릴리스하여 다른 개발자가 사용할 수 있도록 함 해당 컴포넌트를 사용하는 개발자들은 릴리즈 된 버전을 사용, 새 릴리즈를 사용은 각 팀에서 알아서 판단 ..

Key Point 안정된 추상에 의존시키며 구체에 의존 X 소스 코듸 의존성과 제어 흐름은 반대로 -> 이 원칙이 의존성 역전 DIP 의존성 역전 원칙에서 말하는 유연성이 극대화된 시스템이란 소스 코드 의존성이 추상에 의존하며 구체에는 의존하지 않는 시스템 자바와 같은 정적 타입 언어에서 이 말은 import 구문이 오직 인터페이스나 추상 클래스 같은 추상적인 선언만을 참조해야한다는 뜻 구체적인 대상에 절대로 의존해서는 안됨 이러한 아이디어를 규칙으로 보기에는 비현실적 측면이 있음 Java String 구체 클래스 그 예시로 자바의 String은 구체 클래스이며, 이를 추상 클래스로 만드려는 시도는 현실성이 없음. 이 경우 구체 클래스에 대한 의존성은 벗어날 수 없고, 벗어나서도 안됨 String은 매우..

기본적으로 우리는 비즈니스 도메인에 깊이 뿌리내린 모델을 만들어야한다. (핵심 개념을 매우 정확하게 반영하는 모델을 만들어야한다.) 그 다음 우리는 이 모델들을 코드로 구현하는 작업을 수행한다. 최고의 모델을 만들었음에도 코드로 적절하게 바꾸지 못하면, 결국 신뢰할 수 없는 소프트웨어가 만들어진다. 어느 도메인이든 다양한 모델로 표현되고, 각 모델들은 다양한 코드로 표현될 수 있다. 또한 특정 문제에 대한 해법도 여러가지 일 수 있다. 우리는 이중 무엇을 택할 것인가? 우리가 품게되는 근본적인 질문은 모델을 코드로 어떻게 변환할 것인가? 하는 것이다. 분석 모델 설계 기법 코드 설계와 분석을 분리하고 분석과 코드 설계를 보통 서로 다른사람이 작업하도록 한다. 분석 모델은 비즈니스 도메인 분석 결과물일 뿐..

유비쿼터스 언어 소프트웨어 전문가와 도메인 전문가가 이야기하다보면 의사소통 장벽으로 인한 근본적 어려움이 있음 도메인 전문가는 DB가 무엇인지 라이브러리가 무엇인지 알지조차 못한다. 자신의 특화된 분야만 알고있다. 외부인들이 이해하기 어려운 자신들만의 전문용어로 이야기한다. 팀 멤버끼리 도메인에 관해 토의할 수 있는 공통언어를 갖지 못하면 심각한 위험에 직면하게 된다. 우리는 모델을 이야기하고 정의할 때 같은 언어로 말할 필요가 있다. 도메인 주도 설계의 핵심 원칙은 모델 기반의 언어를 사용하는 것 > 모델은 소프트웨어와 도메인이 서로 교차하는 지점이기 때문 모델을 언어의 중추로 사용하라 이 언어를 최대한 끊임없이 사용하도록 요구하라 팀이 사용하는 모든 의사소통 형식에 항상 이 언어가 사용되도록 확인하라..