PHP 테스팅 관련 도구 메모

2022년 8월 5일

테스팅 프레임워크

  • phpunit: 사실상 표준이라 볼 수 있는 php 테스팅 프레임워크.
  • behat: 행위주도 개발(Behavior-Driven Development) php 프레임워크. 사용자 스토리를 작성하고 테스트를 작성할 수 있음.
  • phpspec: BDD php 프레임워크. spec 기반.
  • pestphp: 내부적으론 phpunit이지만 더 간편한 문법으로 테스트를 작성할 수 있는 프레임워크.
  • codeception: 유닛 테스트, 기능 테스트, 인수 테스트(PhpBrowser 또는 WebDriver) 모두 가능한 프레임워크.

테스트 유틸리티

  • faker: 모의 데이터 생성을 돕는 라이브러리.
  • mockery: 모의 개체를 생성하는 php 프레임워크. 개체의 어떤 메소드를 호출하면 어떤 반환값을 반환하는 지 등을 지정해서 테스트 대역으로 활용할 수 있음.
  • Infection: 변조 테스트를 수행해서 각 경계값이 제대로 테스트되는지 확인하는 도구. 예를 들면 count($this->products) === 0 과 같은 코드를 count($this->products) > 0 등으로 변조해서 테스트를 통과하는지 실패하는지 확인하는 방식.
  • churn-php: 리팩토링 후보를 찾는데 도움 주는 도구. 얼마나 많은 커밋에서 해당 파일이 변경되었는지와 로직의 순환 복잡도를 기준으로 순위를 보여줌.
  • ParaTest: phpunit 병렬로 구동하는 도구.
  • roave/better-reflection: 내장 reflection API를 좀 더 사용하기 깔끔하게 만든 라이브러리.

리포트, 코드 분석 도구

코드 커버리지 모범 사례

2022년 7월 24일

Carlos Arguelles, Marko Ivanković, and Adam Bender의 Code Coverage Best Practices를 번역했습니다.


코드 커버리지 모범 사례

저희는 수 년 간 여러 대형 소프트웨어 회사에서 다양한 소프트웨어 테스팅 이니셔티브를 주도했습니다. 꾸준히 강조하는 영역 중 하나는 위험성을 진단하고 테스트의 부족한 부분을 찾아내기 위한 방법으로 코드 커버리지 데이터를 활용하라는 부분입니다. 하지만 코드 커버리지가 제공하는 가치에도 불구하고 논쟁에 불이 붙어 강한 논쟁으로 이어지기도 하고 양극화 양상도 나타나는 주제입니다. 큰 규모의 그룹에서 코드 커버리지를 언급할 때마다 끝없는 논의가 매번 이어지는 것을 볼 수 있었습니다. 이런 대화는 생산성을 향상하는 쪽으로 진행되기 보다는 각자의 방패 뒤로 숨어버리게 합니다. 이 문서는 다양한 의견을 가진 사람들 사이에서 공통의 목표를 제시할 수 있도록 돕고자 작성되었습니다. 커버리지 정보를 좀 더 실용적으로 접근하고 전진에 힘 쓸 수 있도록, 이 문서가 그 도구로 활용되었으면 합니다. 이 글에서는 코드 건강에 효과적으로 도움이 되는 코드 커버리지를 모범 사례를 통해 안내합니다.

  • 코드 커버리지는 개발자의 워크플로에 상당한 이점을 제공합니다. 코드 커버리지가 테스트 품질에 대한 완벽한 지표라고 볼 수는 없지만 논리적이고 객관적인 산업 표준 지표 중 하나로 무언가 조치를 취할 수 있는 정보를 함께 제공합니다. 코드 커버리지는 많은 인적 자원을 필요로 하는 것도 아니라서 모든 프로덕트에 범용적으로 적용할 수 있으며 대부분의 언어에서 사용 가능한 도구가 이미 존재합니다. 물론 코드 커버리지는 많은 정보를 단 하나의 숫자로 표시하기 때문에 손실적이고 간접적인 지표인 점을 이해해야 하며 어떤 문제를 판단하는 유일한 수치가 되어서는 안됩니다. 대신 다른 기법을 함께 활용해서 테스트에 좀 더 종합적인 판단을 내릴 때는 유익한 도움을 받을 수 있습니다.

  • 코드 커버리지가 문제를 줄이는지 아닌지는 아직 명확한 답이 없는, 열린 연구 과제지만 경험에 비춰보면 코드 커버리지를 높이려는 노력이 우수한 엔지니어링을 추구하는 문화로의 변화를 이끄는 경우를 봐 왔고 장기적으로는 문제를 많이 줄이는데 일조했습니다. 예를 들어 팀에 코드 커버리지에 우선 순위를 두면 테스트 자체를 1급 시민처럼 대우해서 테스트 가능성(testability)이 프로덕트 디자인에 더 깊숙히 반영됩니다. 그 결과로 팀은 더 적은 노력으로도 테스트 목표를 달성하게 됩니다. 이 모든 노력은 처음부터 더 고품질의 코드를 작성하는 노력(모듈로 더 분리하고, API에서 더 깔끔한 계약을 작성하고, 더 관리하기 쉬운 코드 리뷰를 수행하는 등)으로 이어집니다. 결과적으로 전반적인 코드 건강, 엔지니어링, 운영 우수성에 대해 신경쓰기 시작합니다.

  • 높은 코드 커버리지 퍼센트는 테스트 범위의 고품질을 보장한다는 의미가 아닙니다. 100%에 가까운 숫자를 만드는 일에만 집중한다면 비뚤어진 안정감을 쫒는 일과 같습니다. 그런 접근에서는 단순히 숫자를 올리기 위해서 가치 낮은 테스트를 양산하기 마련인데 관리해야 하는 테스트가 늘어나기 때문에 기술적 부채를 크게 만듭니다. 또한 테스트에 소모되는 자원까지 고려하면 심한 낭비로 볼 수 밖에 없습니다. 나쁜 코드가 테스트에서 잡히지 않고 프로덕션으로 넘어가게 되었다면 (a) 특정 경로의 코드가 테스트에서 확인되지 않았다는 의미로 이런 부분은 코드 커버리지 분석에서 쉽게 확인할 수 있는 테스트 격차입니다. (b) 또는 테스트가 특정 경계 상황(edge case)에서 제대로 이뤄지지 않은 경우인데 코드 커버리지에서는 테스트를 수행한 것으로 집계되기 때문에 코드 커버리지 분석 만으로 이 부분을 진단하기에는 아주 어렵거나 불가능에 가깝습니다. 코드 커버리지는 코드의 특정 행이나 브랜치가 의도대로 동작되는지 검사하는 도구가 아니라 단순히 테스트에서 실행이 되고 있는지만 보장합니다. 단순히 테스트를 복사/붙여넣기를 하거나 특정 숫자 값을 몇 넣는 것으로 커버리지를 높이는 일이 없도록 더욱 주의해야 합니다. 더 나은 기법이라면 확인하는 각각의 행에 적절한 테스트를 수행하고 실패하는 상황을 잘 검사하고 있는지 확인하기 위해 뮤테이션 테스트를 적용할 수 있습니다.

  • 하지만 낮은 코드 커버리지 수치는 매 자동화된 배포마다 프로덕트의 큰 부분에서 전혀 테스트가 이뤄지지 않는 상황이라는 점을 장담할 수 있습니다. 낮은 수치는 나쁜 코드를 프로덕션으로 내보낼 확률이 높다는 뜻이며 주의 깊게 확인해야 합니다. 실제로 대다수의 코드 커버리지 정보는 어떤 범위가 테스트 되고 있는가 하는 부분보다 어떤 범위가 테스트되지 않고 있는지를 강조합니다.

  • 모든 프로덕트에는 이런 "이상적인 코드 커버리지 수치가 나와야 한다" 같은 규칙은 없습니다. 어느 수준의 테스트를 요구하거나 필요로 하는가 하는 질문은 (a) 비지니스에 얼마나 영향을 미치고 어느 정도 임계가 보장되어야 하는지 (b) 코드에 얼마나 자주 변경이 이뤄지는지 (c) 코드의 생애가 얼마나 장기적인지, 복잡도가 어느 정도인지, 도메인 영역에서의 변수는 어느 정도인지에 따라 답변되어야 합니다. 모든 팀에서 코드 커버리지 몇 퍼센트 달성을 해야 한다고 강제할 수는 없습니다. 이런 비지니스 결정은 프로덕트의 해당 도메인 분야를 잘 이해하는 프로덕트 오너가 내려야 합니다. 코드 커버리지를 특정 퍼센트 달성하기 위해서는 테스트를 더 쉽게 수행할 수 있도록 인프라스트럭처에 대한 투자가 필요합니다. 예를 들면 개발자의 워크플로에 자연스럽게 녹아들 수 있는 도구를 제공하는 등의 방식이 필요합니다. 다만 엔지니어가 단순히 수치를 목표로 삼고 체크 박스 체크하는 것처럼 목표 이상의 커버리지를 달성하는 것만 집중해버리면 아무리 신중하게 코드를 작성 한들 결과적으로는 그다지 건강하지 않을 수 있습니다.

  • 일반적으로 프로덕트 대다수의 코드 커버리지는 평균 이하입니다. 우리는 전반적으로 코드 커버리지를 대폭 상향하는 것을 목표로 해야 합니다. "이상적인 코드 커버리지 수치"가 있는 것은 아니지만 구글에서는 일반적인 가이드라인으로 60%는 "용인되는 수준", 75%는 "칭찬할 만한 수준", 90%는 "모범적인 수준"으로 보고 있습니다. 하지만 전사적 수준에서 하향적인 강제는 하지 않으며 각각의 팀에서 비지니스 요구에 맞춰 얼마를 달성할지 정하도록 격려하고 있습니다.

  • 코드 커버리지 90%에서 95%가 되는 일에 집착하지 않아야 합니다. 코드 커버리지가 주는 이득은 지수적으로 증가하기 때문에 특정 수준을 넘으면 이득이 크지 않습니다. 하지만 30%에서 70%로 가는 일은 구체적인 계획을 짜서 수행하는 것이 바람직합니다. 또한 새로 작성하는 코드는 모두 그 수준을 맞춰서 작성해야 합니다.

  • 테스트에서 다뤄지지 않는 범위의 코드 또는 동작에서 발생할 위험성을 안고 갈 지 아닐지를 사람이 판단하는 점이 코드 커버리지 수치보다 더 중요합니다. 무엇을 테스트하지 않는지 하는 부분이 무엇을 테스트 하는지보다 더 중요한 부분입니다. 코드 리뷰 과정에서 실용적인 토론을 거쳐 어느 행의 코드가 테스트되지 않을지 합의하는 과정이 단순히 목표 숫자를 맞추는 일보다 더 중요합니다. 코드 커버리지를 코드 리뷰 과정에 내장하면 코드 리뷰가 더 빠르고 쉽게 진행됩니다. 모든 코드가 동일하게 주용한 것은 아닙니다. 예를 들면 디버그하는 로그 행을 테스트하는 일은 그다지 중요하지 않습니다. 그래서 개발자는 단순히 커버리지 숫자를 보는 것보다 코드 리뷰에 포함된 테스트로 강조되는 각각의 행을 확인해서 정말 중요한 코드가 테스트되고 있는지 체크해야 합니다.

  • 단순히 프로덕트가 코드 커버리지가 낮다고 해서 장기적으로 구체적이고 점진적인 향상을 할 수 없다는 의미가 아닙니다. 테스트가 별로 없고 테스트가 어려운 레거시 시스템을 인계 받았다면 개선할 힘도 안나고 어디서 시작해야 하는지 전혀 감이 안올 수도 있습니다. 하지만 최소한 '보이스카우트 원칙'을 적용할 수 있을 겁니다. (캠핑장은 처음 왔을 때보다 깨끗하게 해놓고 떠나라.) 시간이 흐르면 점진적으로 더 건강한 위치에 도착하게 될 겁니다.

  • 주기적으로 변경되는 코드는 꼭 테스트에 포함되어야 합니다. 프로젝트의 목표가 넓어서 90% 이상을 달성하는 일이 큰 의미가 없을 수 있습니다. 각 커밋 당 커버리지 목표를 99%로 잡으면 합리적이고 90%는 좋은 하위 임계점으로 볼 수 있습니다. 적어도 시간이 지날 때마다 더 나빠지는 것 만큼은 막아야 합니다.

  • 단위 테스트 코드 커버리지는 퍼즐 조각 하나에 불과합니다. 통합/시스템 테스트 코드 커버리지도 중요합니다. 또한 단위 테스트와 통합 테스트를 포함한 모든 파이프라인에서의 종합 커버리지 수치는 가장 중요합니다. 이 수치는 코드 전체에서 얼마나 많은 영역이 테스트 자동화에 포함되지 않았는지, 그리고 파이프라인을 통해서 프로덕션 환경으로 얼마나 많은 영역이 테스트 없이 보내지는지 알 수 있습니다. 하나 알아야 할 점은 단위 테스트는 실행된 코드와 평가된 코드 사이에서의 상관 관계가 높지만 통합 테스트나 E2E(end-to-end) 테스트에서의 일부 범위는 부수적일 가능성이 크며 의도되지 않은 테스트 범위일 수도 있습니다. 그렇기에 통합 테스트를 코드 커버리지로 같이 본다고 하더라도 그걸 유닛 테스트에서 다뤄지지 않은 범위도 검사가 되고 있구나 착각하는, 비뚤어진 안정감을 갖지 않도록 조심해야 합니다.

  • 코드 커버리지 표준에 미치지 못하면 배포가 되지 않도록 문을 잠궈야 합니다. 물론 팀에서 이런 배포 프로세스를 만들기 전에 충분한 토론을 거쳐서 모두가 납득할 수 있는 수준에서 결정해야 합니다. 하지만 이렇게 프로세스에 넣으면서 단순히 의례적으로 해야 하는 과정으로 체크박스처럼 만들어버리면 역효과가 날 수 있다는 점에 주의해야 합니다. ('목표 달성'에 대한 압박을 주면 절대 원하는 결과를 얻을 수 없습니다.) 여기에는 많은 기법이 존재합니다. 모든 코드에 대한 커버리지를 확인하는 방법과 새 코드에 대한 커버리지만 확인하는 방법도 있습니다. 코드 커버리지를 정량적인 특정 숫자를 기준으로 평가해서 막는 방법도 있고 이전 버전과 비교해서 그 변화량에 맞춰 막는 방법도 있습니다. 또는 특정 범위의 커버리지는 무시하거나 또는 그 범위에만 가중치를 둬서 평가할 수도 있습니다. 이 코드 커버리지에 대한 팀 내의 약속은 잘 지켜져야 합니다. 코드 커버리지를 낮추는 위반이 발생하면 코드가 체크인되지 않고 프로덕션에 도달할 수 없어야 합니다.

만약 구글의 커버리지 인프라스트럭처에 대해 더 알고 싶다면 "Coverage at Google"을 참고하세요. 여기에서 읽을 수 있습니다.

서브타이핑, 서브클래스, 개체 지향 프로그래밍의 문제

2022년 7월 24일

Oleg Kiselyov의 글, Subtyping, Subclassing, and Trouble with OOP를 번역했습니다.


OOP의 인터페이스는 정말 구현과 분리되나요?

구현과 추상을 분리하는 것은 좋은 디자인의 궁극적인 목표 중 하나입니다. 일반적으로 개체 지향 프로그래밍(Object-oriented programming)과 캡슐화(encapsulation)를 통해서 그런 분리를 구현할 수 있다고 주장하며 그로 인해 더 안정적인 코드가 가능하다고 이야기합니다. 최종적으로 프로그래밍 방법론을 진정으로 평가하기 위해서 봐야 할 부분은 생산성과 품질입니다. 이 글은 간단한 예제를 통해서 개체 지향 프로그래밍이 정말 구현을 인터페이스와 분리할 수 있는지 확인합니다. 서브클래스와 서브타입의 차이를 이 예제에서 확인할 수 있습니다. 이 글은 우수한 소프트웨어 공학을 따르는 것으로 시작합니다. 그러므로 좋은 결과가 나오지 않으면 썩 좋은 기분은 아니겠죠.

이 글에서는 좀 더 "실제적인" 예제를 다루는데 촛점을 두고 있어서 직접 실행하고 결과를 볼 수 있습니다. 다만 예제이기 때문에 특정 언어로 구현하기는 해야 해서 여기서는 C++를 사용했습니다. 하지만 다른 개체 지향 언어(자바, 파이썬 등)에서도 비슷한 코드와 유사한 결론을 내리게 될 겁니다.

Bag을 구현하는 일감을 받았다고 가정해봅니다. 이 Bag은 순서 없는 컬랙션으로 중복된 내용을 포함할 수 있습니다. (예시에서는 정수 integer를 사용합니다.) 다음과 같은 인터페이스를 따릅니다.

typedef int const * CollIterator; // 원시적이나 동작합니다
class CBag {
  public:
    int size(void) const;             // bag 안에 있는 엘리먼트의 수
    virtual void put(const int elem); // bag 안에 엘리먼트 넣기
    int count(const int elem) const;  // 제시한 엘리먼트가 bag 안에 몇 차례나
                                      // 나타나는지 확인
    virtual bool del(const int elem); // 제시한 엘리먼트를 bag에서 제거
                                      // 존재하지 않으면 false 반환
    CollIterator begin(void) const;   // 표준 열거자 인터페이스
    CollIterator end(void) const;

    CBag(void);
    virtual CBag * clone(void) const; // bag 복사
  private:
    // 구현 상세는 생략합니다
}

다음은 CBag의 내부 구현을 모르고도 작성할 수 있는 유용한 CBag의 연산자입니다. CBag의 공개 인터페이스만 갖고 다음 함수를 작성할 수 있습니다.

// 표준 "print-on" 연산자
ostream& operator << (ostream& os, const CBag& bag);

// 두 bag을 병합합니다.
// 서브클래스의 복잡함을 피하기 위해 반환 타입은 void로 지정합니다.
// (현재 예시에서는 부수적인 부분이기 때문입니다)
void operator += (CBag& to, const CBag& from);

// a가 b의 하위 bag인지 판단합니다.
bool operator <= (const CBag& a, const CBag& b);

inline bool operator >= (const CBag& a, const CBag& b)
{ return b <= a; }

// bag의 구조적 동치를 확인합니다.
// 만약 동일한 갯수의 동일 엘리먼트를 반환하면 동일한 백입니다.
inline bool operator == (const CBag& a, const CBag& b)
{ return a <= b && a >= b; }

강조하고 싶은 부분은 CBag의 세부적인 구현을 알아야 하는 기능 수를 최소가 되도록 패키지를 설계했다는 점입니다. 검증 코드에서는 모든 CBag 패키지에 있는 모든 함수와 메소드를 테스트했고 일반적인 무공변성(invariant)을 검증했습니다.

이제 Set 패키지를 만들어야 한다고 지시를 받았다고 칩시다. 상사가 설명하기를 set은 순서 없는 컬렉션으로 각 엘리먼트는 꼭 하나만 존재해야 한다고 합니다. 즉, 중복이 없는 bag을 구현하려고 합니다. 이제 CBag 패키지를 보면 몇 가지 추가적인 변경이 필요하다는 걸 알게 될겁니다. bag을 활용해 Set을 정의한다면 CBag의 코드를 몇 가지 제약과 함께 재사용해서 간단하게 작성 할 수 있을 것으로 판단했습니다.

class CSet : public CBag {
  public:
  bool memberof(const  int elem) const { return count(elem) > 0; }

  // CBag::put을 오버라이드 합니다
  void put(const int elem)
  { if (!memberof(elem)) CBag::put(elem); }

  CSet * clone(void) const
  { CSet * new_set = new CSet(); *new_set += *this; return new_set; }
  CSet(void) {}
}

CSet과 CBag을 섞어 쓸 수 있게 CSet이 정의되었습니다. 다시 말하면 set += bag;이나 bag += set;도 동작합니다. 이런 연산자는 잘 정의가 되어 있어서 set은 각 엘리먼트가 딱 하나만 있도록 숫자를 세고 있게 구현되어 있습니다. 예를 들어서 set += bag;은 bag에 있는 모든 엘리먼트 중 이미 없는 것만 set에 추가합니다. bag += set;은 다른 bag과 병합하는 것과 다르지 않습니다.

CSet의 모든 메소드를 검증하는 테스트를 작성할 수 있을겁니다. (새로 작성한 것이나 bag에서 상속받은 것을 말이죠.) 일반적인 속성도 검증할 수 있습니다. 예를 들면 a+=aa입니다.

제 패키지에는 다음처럼 함수를 정의하고 구현했습니다.

// 예시 함수. 3개의 bag (a, b, c)를 받아서 a+b가 c의 하위 bag인지 검사.
bool foo(const CBag& a, const CBag& b, const CBag& c)
{
  CBag & ab = *(a.clone()); // 먼저 다른 영향이 없도록 복제합니다.
  ab += b;                  // ab는 이제 a와 b의 병합 bag이 됩니다.
  bool result = ab <= c;
  delete &ab;
  return result;
}

이 코드는 회귀 테스트에서 검증되었습니다. set으로 동일하게 작성해도 동작하는 것을 확인할 수 있습니다.

이후에 ab 개체가 불필요하게 힙 영역을 잡아먹는 것을 발견했습니다. 이 비효율을 개선하기 위해 다음처럼 다시 작성했습니다.

bool foo(const CBag& a, const CBag& b, const CBag& c)
{
  CBag ab;
  ab += a;
  ab += b;
  bool result = ab <= c;
  return result;
}

원래의 foo()와 완전히 동일한 인터페이스를 갖고 있습니다. 코드는 거의 변경하지 않았습니다. CBag 패키지만 생각한다면 새로운 구현도 동일하게 동작합니다. 하지만 저는 누가 제 CBag 패키지를 가져다가 쓰고 있는지 전혀 모릅니다. 여기서는 foo()를 대상으로 회귀 테스트를 다시 구현했고 모든 결과가 정상으로 나왔습니다.

하지만 새로 구현한 foo()와 함께 코드를 돌리면 무언가 달라졌다는 점을 알게 될 겁니다! 직접 코드 전체를 받아서 확인해보세요. vCBag1vCBag2를 만들어서 foo() 함수의 첫 구현과 두 번째 구현을 대상으로 테스트를 검증해보세요. 두 테스트는 모두 성공함과 동시에 동일한 결과를 반환합니다. 이제 vCSet1vCSet2를 만들어서 CSet 패키지를 테스트합니다. foo() 테스트만 제외하고 모두 성공할 겁니다. 이상하게도 foo() 결과가 달라졌습니다. 어느 foo() 구현이 CSet에 맞는 답을 반환하고 있는지는 논의의 여지가 있습니다. 어떤 쪽이 맞는 답이든 간에 순수 함수 foo()가 동일한 인터페이스를 따르고 있다면 잘 동작하는 코드를 고장내는 일은 없어야 할겁니다. 무슨 일이 일어난 걸까요?

특히 이 문제는 두 구현이 모두 교과서적인 방식대로 이뤄졌기 때문에 더 심란합니다. 안전하게 타입을 확인하고 코드를 작성했습니다. 캐스팅도 하지 않았습니다. g++ (2.95.2) 컴파일러를 사용하면서 -W-Wall 플래그를 활성화해도 경고 하나 존재하지 않습니다. 평소에는 엄청 귀찮게 만드는 플래그인데도 말이죠. 고의적으로 고장내려고 CBag의 메소드를 수정하거나 한 것도 아닙니다. CBag의 무공변성을 유지하기도 했습니다. (필요에 따라서 약간 약화시킨 부분도 있지만요.) 실제 세계의 클래스라면 대수학의 속성보다 더 불분명한 형태로 작성될 겁니다. 여기서는 CBag과 CSet 모두 회귀 테스트를 작성했고 테스트를 통과했습니다. 여기서 인터페이스와 구현을 분리하려는 모든 노력이 실패로 돌아갔습니다. 프로그래밍 언어나 프로그래밍 방법론이 이 문제에 대한 책임이 조금이라도 있는 건 아닐까요?

서브타입과 서브클래스

CSet의 문제점은 CSet의 디자인이 리스코프 치환 원칙(Liskov substitution principle, LSP)를 위반했기 때문입니다. CSet은 CBag의 서브클래스로 선언되었습니다. 그러므로 C++ 컴파일러의 타입체커는 CSet 개체를 전달하거나 함수에서 CSet 참조를 수행할 때 CBag 개체나 참조도 문제 없이 통과시킵니다. 그러나 CSet은 CBag의 서브타입이 아닙니다. 이 부분은 아래에서 간단한 증명으로 살펴보겠습니다.

Bags와 Sets를 순수 으로 고려해서 어떤 상태나 고유한 동작을 수행하지 않는 형태로 만드는 것도 한 방식이 될 수 있습니다. 즉, 정수처럼 다룬다는 이야기죠. (이 문제 해결 글에서 다룹니다.) 또 다른 방식은 개체 지향 프로그래밍으로 개체에 상태와 동작을 캡슐화 하는 접근법입니다. 동작의 의미는 개체가 메시지를 받거나 응답을 보내고, 상태도 변경할 가능성도 있다는 뜻입니다. Bag과 Set의 관계는 제쳐두고 둘을 따로 생각해봅시다. 여기서는 논의를 조금 더 명확하게 하기 위해서 간결한 표기법을 활용하겠습니다.

Bag을 개체로 정의하고 두 메시지를 받는다고 가정합니다.

(send a-Bag 'put x)     ; x 엘리먼트를 bag에 넣습니다.
(send a-Bag 'count x)   ; x 엘리먼트가 몇 개 있는지 확인합니다.
                        ; 그 과정에서 상태를 변경하지 않습니다.

이제 Set도 비슷하게 정의합니다.

(send a-Set 'put x)     ; x 엘리먼트를 set에 (존재하지 않으면) 넣습니다.
(send a-Set 'count x)   ; x 엘리먼트가 set에 몇 개 있는지 확인합니다.
                        ; (항상 0 또는 1이 나옵니다.)

이제 함수를 생각해봅시다.

(define (fnb bag)
  (send bag 'put 5)
  (send bag 'put 5)
  (send bag 'count 5))

이 함수의 동작은 다음처럼 정리할 수 있습니다. "Bag이 하나 제공되면 두 엘리먼트를 추가하고 반환한다."

(+2 (send orig-bag 'count 5))

기술적으로는 fnb 함수에 Set 개체를 전달하는 것이 가능합니다. Bag이 putcount 메시지를 이해할 수 있는 것처럼 Set도 이해하기 떄문입니다. 하지만 fnb에 Set 개체를 넣으려고 하면 위에서 명시된 것처럼 함수의 사후 조건(post-condition)을 어기게 됩니다. 그러므로 set 개체를 bag 개체가 필요한 곳에 넣으면 어떤 프로그램에서 기대했던 동작이 달라지게 됩니다. 리스코프 치환 원칙(LSP)에 따르면 Bag을 Set으로 치환할 수 없고 Set은 Bag의 서브타입이 될 수 없습니다.

다음 함수를 고려해봅니다.

(define (fns set)
  (send set 'put 5)
  (send set 'count 5))

이 함수의 동작은 이렇습니다. "Set이 하나 제공되면 엘리먼트를 하나 추가하고 1을 반환한다." 이 함수에 bag을 전달하면 fns 함수는 1보다 큰 수를 반환할 수도 있습니다. (왜냐면 bag도 putcount를 구현하고 있기 때문입니다.)

그러므로 개체지향 관점에서 본다면 Bag과 Set은 어느 쪽의 서브타입도 아닙니다. 이게 이 문제에서 가장 중요한 부분입니다. Bag과 Set은 단지 닮았을 뿐입니다. Bag과 Set의 인터페이스와 구현은 그 유사성 때문에 서로를 서브타입으로 삼으려고 합니다. 다만 그렇게 서브타입으로 만드는 것으로 LSP를 위반하게 됩니다. 위에서처럼 눈에 잘 띄지 않는 오류를 마주할 각오를 해야만 할겁니다. 위에서 든 예제는 LSP를 의도적으로 어겨서 어떻게 교활한 오류를 만들어 내는지, 그리고 얼마나 찾아내는데 어려운지 보여줬습니다. Set과 Bag은 아주 비슷하면서도 간단한 타입으로 실무에서 만나게 될 코드보다 훨씬 단순한 예시입니다. OOP의 관점에서 봤을 때 LSP는 명확하게 들어나지 않는 부분인 것을 감안해야 합니다. 컴파일러가 이 문제를 지적해주리라고 기대하기는 어렵습니다. 회귀 테스트에도 의존할 수 없습니다. 수작업으로 직접 문제를 봐야만 알 수 있습니다.

서브타입과 불변성

누구는 이렇게 얘기할 수도 있습니다. "Set은 Bag이 아니지만 불변 Set은 불변 Bag입니다", 라고 말이죠. 하지만 그렇지도 않습니다. 불변성을 얘기한다고 하더라도 파생된 데이터 클래스를 서브타입으로 고려할 수는 없습니다. 앞서 예제와는 조금 다른 다음 코드를 살펴봅시다. 다시 C++ 코드로 보겠지만 다른 코드로 작성하더라도 이 예제는 동일할 겁니다.

class BagV {
  virtual BagV put(const int) const;
  int count(const int) const;
  // ... // 다른 유사한 const 멤버
}

class SetV {
  virtual SetV put(const int) const;
  int count(const int) const;
  // ... // 다른 유사한 const 멤버
}

BagV와 SetV의 인스턴스는 불변입니다. 하지만 각 클래스는 여전히 서로의 서브타입이 아닙니다. 다음과 같은 폴리모픽(polymorphic) 함수를 생각해봅시다.

template <typename T> int f(const T& t)
{ return t.put(1).count(1); }

BagV 인스턴스에서 다음 함수의 동작은 무공변적으로 표현할 수 있습니다.

f(bag) == 1 + bag.count(1)

만약 asetv = SetV().put(1)처럼 할당하고 f()에 전달하면 위의 무공변성을 어기게 됩니다. 정리하면 이렇습니다. LSP에 의해서 SetV는 BagV를 치환할 수 없습니다. 그러므로 SetV는 BagV가 아닙니다.

위 함수를 다시 정의하면 이렇습니다.

int fb(const BagV& bag) { return bag.put(1).count(1); }

물론 SetV 인스턴스를 지금도 이 함수에 넣을 수는 있습니다. 예를 들면 SetV를 BagV의 서브클래스로 만들거나 reinterpret_cast<const BagV&>(aSetV)식으로 집어넣을 수 있습니다. 이렇게 작성하면 오류가 발생하지는 않지만 fb()의 무공변성을 깨고 프로그램의 동작을 예측할 수 없는 방향으로 바꾸게 됩니다. "BagV는 SetV의 서브타입이 아니다", 라는 명제에도 유사한 논의가 가능합니다.

C++ 개체는 레코드 기반입니다. 서브클래스는 래코드를 확장하는 방법이며 부모 레코드의 일부를 수정할 가능성이 존재합니다. 이 일부 영역에 대해서는 수정이 가능하다는 명시적인 표시를 위해 virtual 키워드를 사용합니다. 이 맥락에서 보면, 변형을 방지하면서도 동작을 덮어 쓸 수 있게 했지만 동시에 서브클래스가 서브타입을 수반하게 만듭니다. 이게 B규칙이 존재하는 이유입니다.

하지만 개체의 상태를 불변성으로 선언하는 것만으로는 서브타입으로 파생되지 않도록 보장하기에 충분하지 않습니다. 개체는 부모를 직접 수정하지 않고도 부모의 동작을 덮어쓸 수 있습니다. 개체가 함수 클로저처럼 메시지를 받을 때 응답형으로 콜백 등의 핸들러가 있거나 프로토타입 기반의 개체지향 시스템에서는 부모 클래스를 수정하지 않고도 동작을 조작할 수 있습니다. 파생 개체가 기반 개체를 수정할 수 있다면 동작 덮어쓰기를 암묵적으로 허용하는 것이나 마찬가집니다. 예를 들어 A 개체가 내부에 B 개체를 저장해놓고 M 메시지를 받을 때마다 B 개체에 전달해주는 경우를 생각해봅시다. A 개체에서 파생한 C 개체가 그 내부 동작을 덮어쓴다면 여전히 M 메시지를 받으면서도 다른 형태로 동작하게 됩니다.

예를 들면 Scheme에서 순수 함수형 개체지향 시스템을 구현할 수 있습니다. 개체의 독자성, 상태, 동작, 상속과 다형성까지 지원하며 시스템 내 모든 것이 불변입니다. 하지만 여전히 BagV와 같은 것도 정의할 수 있으며 SetV를 put 메시지 핸들러를 덮어쓰는 방식으로 파생시켜 사용하는 것도 가능합니다. 다만 이런 접근 방식은 여기서도 좋지 않고 앞서 LSP를 어겼을 때 나타나는 문제와 유사합니다. 이 예시는 불변성 또한 개체 파생에서 나타나는 서브타이핑 문제에 자유롭지 않다는 점을 보여줍니다.

#

2022년 7월 23일

자꾸 엉킨 실타래처럼 시작과 끝을 모르는 고민을 자꾸 하게 돼서 어떻게든 적어보려고 컴퓨터를 켰는데 어디서 시작해야 할 지 잘 모르겠다. 어떻게 모든 일이 꾸역꾸역 해야만 진행이 되는 느낌일까. 미루기 전문가라서 그런 것이 분명하다.

회사를 다닌 지 한 달 반 정도 지났다. 원래 들어가기로 했던 프로젝트는 여러 이유로 미뤄졌다. 그래서 늘 하던 종류의 업무를 몇 받게 되었는데 이전 회사에서도 오래 해왔던 업무라서 큰 부담이 없었다. 익숙한 패턴으로 진행되는 자잘한 업무에서 마음이 차분해졌다. 그동안 일을 쉰 기간도 있으니 적응에 시간이 걸릴까 걱정한 것도 무색해졌다. 비지니스에서 필요로 하는 크고 작은 일을 꼼꼼하게 보고 서둘러 처리하는 일. 해야 하는 일의 범위는 넓지만 자세히 보면 다 거기서 거기인 그런 일들. 숨 쉬는 것처럼 익숙한 일감을 큰 고민 없이 척척 해냈다. 이런 작업이라면 학교 다니면서도 충분히 할 수 있지 않을까, 그런 자신감까지 챙겼다. 그러던 중 프로젝트에 참여하는 날이 왔다. 몇 주 간 익숙한 업무 사이에서 쌓아온 자신감은 일주일 만에 바닥을 드러냈다.

처음 맡은 일감은 겉은 쉬워 보이면서도 프로젝트를 속속 알아야만 할 만한 그런 일이었다. 어떤 일이든 배워서 하면 되는 거야, 난 늘 그런 각오가 되어 있었다. 나는 약간 나를 태워가면서 일하는 사람이니까. 하지만 일에 나를 온전히 던지는 나는 과거의 나였다. 지금의 나는 또 다르더라. 내가 가고 싶은 방향이 이게 맞는 걸까, 여기에 시간을 쓰고 일을 배우는 것이 합당한가 따지는 이상주의자와, 학비를 어떻게든 마련해야 하니까 이건 와신상담의 자세로 맞서야 한다 생각하는 현실주의자의 싸움이었다.

물론 현실주의자의 승리다. 당장은.

한 발 물러나서 생각해보면 이런 여유 없음 당연한 것이다. 회사 다니기 시작하면 첫 세 달은 적응에 정신 없기 마련이다. 일 안하는 기간 동안 그냥 지낸 것도 아니고 자잘한 토이 프로젝트도 하고 학교도 부지런히 다녀서 좋은 성적 냈는데. 왜 자꾸 자신 없는 나라는 틀에 들어가려고 하는지 모르겠다. 게다가 무슨 일이 하고 싶은지 정확하게 모르면서 막연한 상상에만 집착하니까 겉으로만 도는 것이 분명하다. 어떻게든 해결하려고 해도 막연하기만 하니까 시작할 것도 명확하지 않다. 그래서 고민의 쳇바퀴에서 습관처럼 뛰고 있는 것이다. 그렇게 시작이 없으면 고민만 늘어난다. 그러니까 무엇이라도 시작해야 한다.

시작해야 한다. 무엇이라도. 요즘 하는, 많은 고민들의 답이 거기에 있는 것 같다.

PHP 열거형(enumerations) 정리

PHP 8.1부터 추가된 열거형 타입 살펴보기

2022년 7월 17일

PHP 8.1에 열거형이 추가되었습니다. 그동안 클래스와 클래스 상수를 사용해서 열거형처럼 사용했었는데 용도에 맞게 사용할 수 있는 타입이 생겼습니다.

Enumerations - php를 중점으로 번역했습니다.

열거형, "Enums"는 제한된 선택지를 정의할 수 있는 타입입니다. [...] 각 언어마다 다양한 구현이 있지만 PHP에서는 특별한 종류의 개체로 처리합니다. Enum 자체는 클래스지만 각각 케이스를 단일 인스턴스 개체로 다루는 것도 가능합니다. 즉, 개체를 사용하는 곳이라면 어디든 열거형 케이스를 적용할 수 있습니다. -- Enumerations overview - PHP

열거형 기초

열거형을 다음처럼 선언할 수 있습니다.

enum Suit
{
  case Hearts;
  case Diamonds;
  case Clubs;
  case Spades;
}

열거형 타입으로 Suit를 작성했고 4가지 허용된 값으로 Suit::Hearts, Suit::Diamonds, Suit::Clubs, Suit::Spades를 선언했습니다. 이 값을 직접 사용하거나 변수에 할당해서 사용하는 것도 가능합니다.

function pick_a_suit(Suit $s)
{
  // ...
}

pick_a_suit(Suit::Diamonds);

// 변수에 할당하는 것도 가능
$suit = Suit::Clubs;
pick_a_suit($suit);

pick_a_suit('Hearts');
// TypeError: pick(): Argument #1 ($suit) must
//   be of type Suit, string given...

각 케이스는 별도 정의가 없으면 스칼라 값으로 다뤄지지 않습니다. 내부적으로는 해당 이름의 싱글턴 개체가 존재하기 때문에 다음처럼 작성하는 것도 가능합니다.

$a = Suit::Spades;
$b = Suit::Spades;

$a === $b; // true
$a instanceof Suit; // true

여기서 Suit 타입의 케이스는 별도 데이터를 지정하지 않았기 때문에 "순수 케이스(Pure case)"로 불립니다. 순수 케이스만 포함된 열거형은 순수 열거형(Pure Enum)으로 부릅니다. 모든 순수 케이스는 해당 열거형 타입의 인스턴스로 구현되어 있으며 열거형 타입은 내부적으로는 클래스처럼 동작합니다.

모든 케이스는 읽기 전용 프로퍼티로 name이 존재하며 케이스 이름을 문자열로 반환합니다.

print Suit::Spades->name; // "Spades"

지원 열거형 (Backed enumerations)

위에서 본 열거형은 스칼라 값이 없는, 순수한 형태입니다. 하지만 데이터를 저장한다던지 직렬화 해야 하는 경우에는 열거형에 기본값이 있으면 더 유용하게 사용할 수 있습니다.

스칼라 값을 사용하는 열거형은 다음처럼 작성합니다.

enum Suit: string
{
  case Hearts = 'H';
  case Diamonds = 'D';
  case Clubs = 'C';
  case Spades = 'S';
}

여기서 케이스는 간단한 스칼라 값의 "지원을 받는" 케이스(backed case)입니다. 모든 케이스가 지원 케이스인 열거형을 지원 열거형(Backed Enum)이라고 합니다.

이 지원 열거형은 intstring과 함께 사용할 수 있습니다. 동시에 둘을 지원할 수는 없습니다. 즉, int|string은 안됩니다. 어느 타입이든 지정하면 모든 케이스에서 값이 존재해야 합니다. 즉, int로 지정한다고 하더라도 자동으로 값이 지정되지 않습니다. 또한 각각 케이스의 값은 열거형 내에서 유일해야 합니다.

지정된 값은 리터럴 또는 리터럴 표현식이어야 합니다. 상수와 상수 표현식은 지원되지 않습니다. 즉, 1 + 1은 값으로 지정할 수 있는 표현식이지만 1 + SOME_CONST는 불가능합니다.

지원 케이스도 value라는 읽기 전용 프로퍼티를 제공합니다. 정의할 때 지정한 값을 반환합니다.

print Suit::Clubs->value; // "C"

이 지원 열거영은 내부적으로 BackedEnum 인터페이스를 구현하고 있습니다. 이 인터페이스는 from(int|string): selftryFrom(int|string): ?self 메소드를 포함하고 있습니다. 이 메소드는 다음처럼 활용할 수 있습니다.

enum InvoiceState: string {
  case New = 'new';
  case Paid = 'paid';
  case Confirmed = 'confirmed';
  case Completed = 'completed';
  case Invalid = 'invalid';
}

$invoice = ['id' => 1, 'state' => 'new'];

print $invoice['state']; // 'new'

// 열거형에 정의하지 않은 값으로 테스트
$invoice['state'] = 'half-paid';

$state = InvoiceState::from($invoice['state']);
// Uncaught ValueError: "half-paid" is not a valid
//    backing value for enum "InvoiceState" in...

$state = InvoiceState::tryFrom($invoice['state'])
          ?? InvoiceState::Invalid;

print $state->value; // 'invalid'

이 두 함수를 직접 정의하려고 하면 오류가 발생하니 주의하세요.

열거형 메소드

열거형에도 메소드를 작성할 수 있으며 인터페이스를 구현하는 것도 가능합니다.

interface Colorful
{
  public function color(): string;
}

enum Suit implements Colorful
{
  case Hearts;
  case Diamonds;
  case Clubs;
  case Spades;

  // 클래스처럼 메소드 작성
  public function shape(): string
  {
    return 'Rectangle';
  }

  // Colorful 인터페이스를 구현
  public function color(): string
  {
    return match($this) {
      Suit::Hearts, Suit::Diamonds => 'Red',
      Suit::Clubs, Suit::Spades => 'Black',
    };
  }
}

function paint(Colorful $c) { /* ... */ }

paint(Suit::Clubs);

print Suit::Diamonds->shape(); // 'Rectangle'

유심히 봐야 할 부분은 메소드 내에서 사용한 $this입니다. 각 열거형 케이스는 내부적으로 인스턴스가 존재하기 때문에 호출된 케이스를 $this로 접근할 수 있게 됩니다. 문법의 모습은 정적 클래스와 유사하기만 할 뿐 맥락이 다르다는 점을 확인할 수 있습니다.

참고로 위 구현은 온전히 예시로 작성되었으며 실제라면 별도의 SuitColor 열거형으로 구현하는 게 바람직합니다.

메소드의 접근자는 public, private, protected 모두 가능하지만 열거형은 상속이 불가능하기 때문에 private과 protected 사이에 실질적인 차이는 없습니다.

열거형 정적 메소드

열거형에 정적 메소드를 정의할 수 있습니다. 아래 코드는 정적 메소드를 별도의 생성자처럼 사용하는 예제입니다.

enum Size
{
  case Small;
  case Medium;
  case Large;

  public static function fromLength(int $cm): static
  {
    return match(true) {
      $cm < 50 => static::Small,
      $cm < 100 => static::Medium,
      default => static::Large,
    };
  }
}

열거형 상수

열거형에 상수도 선언할 수 있습니다. 상수로 열거형 케이스를 지정하는 것도 가능합니다.

enum Size
{
  case Small;
  case Medium;
  case Large;

  // 열거형 케이스를 할당
  public const Huge = self::Large;

  // 이런 것도 그냥 할 수 있음
  private const Someone = 'hello';
}

트레이트 (traits)

클래스처럼 동작하기 때문에 트레이트를 사용할 수 있습니다. 다만 프로퍼티가 존재하는 트레이트는 오류가 발생합니다.

trait Rectangle
{
  public function shape(): string {
    return "Rectangle";
  }
}

enum Suit implements Colorful
{
  use Rectangle;

  // ...
}

열거형과 개체의 차이점

열거형은 클래스와 개체로 구현되어 있지만 모든 개체 관련 기능을 사용할 수는 없습니다. 특히 열거형은 상태를 가질 수 없습니다.

  • 생성자, 소멸자 사용 금지
  • 상속 미지원
  • 정적 또는 개체 프로퍼티 금지
  • 열거형 케이스를 복제(cloning)하는 행위 금지
  • __call, __callStatic, __invoke 이외 매직 메소드 금지

또 다음과 같은 특징이 있습니다.

  • __CLASS__, __FUNCTION__ 상수 사용 가능
  • ::class 매직 상수는 열거형과 열거형 케이스에 동일하게 사용할 수 있지만 둘 다 열거형의 클래스명을 반환
  • 접근자 사용 가능
  • 인터페이스 상속 가능
  • 어트리뷰트 사용 가능

값 목록

열거형은 내부적으로 UnitEnum 인터페이스를 구현하고 있으며 cases() 정적 메소드를 제공합니다. 열거형에 선언된 모든 케이스를 담은 배열을 반환합니다.

var_dump(Size::cases());
// [Size::Small, Size::Medium, Size::Large]

직렬화(Serialization)

열거형 직렬화는 개체 직렬화는 다른 방식으로 구현되어 있습니다. 특히 역직렬화 할 때는 기존 싱글톤 값을 그대로 사용할 수 있어서 다음과 같은 동작이 보장됩니다.

Suit::Hearts === unserialize(serialize(Suit::Hearts));
// true

print serialize(Suit::Hearts);
// 'E:11:"Suit::Hearts";'

순수 열거형은 JSON으로 직렬화 시 오류가 발생합니다. 지원 열거형은 표현하고 있는 스칼라 값만 남게 됩니다. 이런 기본 동작은 JsonSerializable 인터페이스를 구현하는 것으로 대체할 수 있습니다.

예제

제한적인 기본값 지정

enum SortOrder
{
  case ASC;
  case DESC;
}

function query(
  $fields,
  $filter,
  SortOder $order = SortOrder::ASC,
) {
  /* ... */
}

match()와 함께 활용하기

enum UserStatus: string
{
  case Pending = 'P';
  case Active = 'A';
  case Suspended = 'S';
  case CanceledByUser = 'C';

  public function label(): string
  {
    return match($this) {
      static::Pending => 'Pending',
      static::Active => 'Active',
      static::Suspended => 'Suspended',
      static::CanceledByUser => 'Canceled by user',
    };
  }
}

//...

foreach (UserStatus::cases() as $case) {
  printf(
    '<option value="%s">%s</option>\n',
    $case->value,
    $case->label(),
  );
}
/**
 * result:
 * <option value="P">Pending</option>
 * <option value="A">Active</option>
 * <option value="S">Suspended</option>
 * <option value="C">Canceled by user</option>
 */

포트와 어댑터 아키텍처: PHP 예제

2022년 7월 17일

포트와 어뎁터 아키텍처(ports and adapters architecture)는 육각형 아키텍처(hexagonal architecture)로도 불린다.

(육각형 아키텍처를 통해) UI나 데이터베이스 없이 동작하는 어플리케이션을 만듭니다. 그래서 어플리케이션을 자동화된 테스트를 반복해서 수행할 수 있고, 데이터베이스가 없을 때도 동작 가능하며, 사용자 없이도 애플리케이션을 연결할 수 있습니다.

외부와 어플리케이션, 도메인을 육각형 도식으로 명확하게 분리한다. 각 분리된 영역은 항구(port)를 통해 소통하는 구조를 따른다. 코드의 의존성을 "설정"하는 것으로 필요에 따라서, 재사용 할 수 있다는 점을 강조한다.

만들면서 배우는 클린 아키텍처의 예제 코드를 보면서 php로 작성했다. 어느 스터디 그룹에서 정리한 리포지터리에도 잘 정리되어 있어서 같이 보면 유익하다.

코드

다만 의존성 구조를 체크하는 테스트는 아직 옮기지 못했다. (Alistair의 글에서 보면 이 부분도 매우 중요하다고 언급한다.)

패키지 구조

./src
├── Account
│   ├── Adapter
│   │   ├── In
│   │   │   ├── Console
│   │   │   │   ├── BalanceConsoleCommand.php
│   │   │   │   └── SendConsoleCommand.php
│   │   │   └── Web
│   │   └── Out
│   │       └── Persistence
│   │           ├── AccountMapper.php
│   │           ├── AccountObjectEntity.php
│   │           ├── AccountObjectEntityRepository.php
│   │           ├── AccountPersistenceAdapter.php
│   │           ├── ActivityObjectEntity.php
│   │           └── ActivityObjectEntityRepository.php
│   ├── Application
│   │   ├── Port
│   │   │   ├── In
│   │   │   │   ├── GetAccountBalanceQuery.php (interface)
│   │   │   │   ├── SendMoneyCommand.php
│   │   │   │   └── SendMoneyUseCase.php (interface)
│   │   │   └── Out
│   │   │       ├── AccountLock.php (interface)
│   │   │       ├── LoadAccountPort.php (interface)
│   │   │       └── UpdateAccountStatePort.php (interface)
│   │   └── Service
│   │       ├── GetAccountBalanceService.php
│   │       ├── MoneyTransferProperties.php
│   │       ├── NoOpAccountLock.php
│   │       ├── SendMoneyService.php
│   │       └── ThresholdExceededException.php
│   └── Domain
│       ├── Account.php
│       ├── AccountId.php
│       ├── Activity.php
│       ├── ActivityId.php
│       ├── ActivityWindow.php
│       └── Money.php
├── Common
│   ├── ConsoleAdapter.php (interface)
│   ├── PersistenceAdapter.php (interface)
│   └── UseCase.php (interface)
└── Kernel.php

./tests
├── Account
│   ├── Adapter
│   │   ├── In
│   │   │   └── Console
│   │   │       ├── BalanceCommandTest.php
│   │   │       └── SendCommandTest.php
│   │   └── Out
│   │       └── Persistence
│   │           └── AccountPersistenceAdapterTest.php
│   ├── Application
│   │   └── Service
│   │       └── SendMoneyServiceTest.php
│   └── Domain
│       ├── AccountTest.php
│       ├── ActivityWindowTest.php
│       └── MoneyTest.php
├── DataFixtures
│   └── AppFixtures.php
├── Helpers
│   └── CommandTestTrait.php
├── TestData
│   ├── AccountBuilder.php
│   ├── AccountTestData.php
│   ├── ActivityBuilder.php
│   └── ActivityTestData.php
└── bootstrap.php