[Clean Architecture] Test Boundary, Clean Architecture

휴먼스케이프

클린 아키텍처의 테스트 경계(Test Boundary)와 클린 임베디드 아키텍처에 대해 알아봅니다.

The test boundary, 출처 : Clean Architecture

안녕하세요. 휴먼스케이프 테드 입니다.

오늘은 테스트 경계와 클린 임베디드 아키텍처에 대해 알아보려고 합니다.

테스트 경계(The test boundary)

테스트는 시스템의 일부이며, 시스템의 나머지 요소들처럼 아키텍처에도 관여 합니다. 아키텍처 관점에서 모든 테스트(unit, integration, argument, 기능, cucumber, TDD, BDD, component 테스트)는 동일합니다.

테스트는 다음과 같은 특징이 있습니다.

태생적으로 테스트 대상이 되는 코드를 향해 의존성 규칙을 따릅니다.

독립적으로 배포가능합니다. 사실 대다수의 경우 테스트는 테스트 시스템에만 배포하고, 상용 시스템에는 배포하지 않습니다.

시스템 컴포넌트 중에서 가장 고립되어 있습니다. (운영이 아닌 개발을 지원함)

Fragile Tests Problem

시스템에 강하게 결합된 테스트라면 시스템이 변경될 때 함께 변경되어야해서 사소한 변경된 수많은 테스트를 망가뜨릴 수 있습니다. (예: UI)

이런 경우에 개발자는 변경을 하지 않으려고 하는 경향이 생기게 됩니다.(조금 수정하는 데 테스트 코드를 1,000 개 수정한다고 생각해 봅시다.)

UI와 같이 변동성이 있는 것에 의존하지말고 업무 규칙을 테스트 할 수 있어야 합니다.

테스트에 특화된 API를 별도로 만들어 테스트 구조를 애플리케이션 구조로부터 결합을 분리할 수 있도록 테스트 API 를 만드는 것도 한 방법입니다. 그렇게 되면 구조적 결합을 느슨하게 만들어 범용성과 유연성에 대응할 수 있게 됩니다. 테스트 API 중 위험한 부분의 구현부는 독립적으로 배포할 수 있는 컴포넌트로 분리해야 합니다.

“테스트를 유지보수하기 힘들게 되면 결국 방바닥 휴지처럼 버려지는 최후를 맞게 됩니다.”

클린 임베디드 아키텍처(Clean Embeded Architecture)

“소프트웨어는 닳지 않지만, 펌웨어와 하드웨어는 낡아 가므로 결국 소프트웨어도 수정해야 한다.”

소프트웨어는 닳지 않지만, 펌웨어와 하드웨어에 대한 의존성을 관리하지 않으면 안으로부터 파괴될 수 있습니다.

펌웨어는 저장되는 위치로 정의되지 않습니다. 이보다는 무엇에 의존하는지, 하드웨어 발전에 맞춰 수정하기가 얼마나 어려운지 따라 정의됩니다.

임베디드 개발자들은 임베디드가 아니었다면 다루지 않아도 될 특수한 관심사를 많이 가지고 있습니다. 예를 들면 제한된 메모리 공간, 실시간성 제약과 처리완료 시간, 제한된 입출력, 특이한 사용자 인터페이스, 여러 센서와 실제 세상과의 상호작용 등입니다. 더 어렵게 만드는 것은 개발 시점에 코드를 실행할 대상 조차도 없을 수 있습니다. 심지어는 하드웨어가 준비되더라도 하드웨어 자체에 결함이 있을 가능성이 높습니다 ㅠㅠ

아래는 임베디드를 위해서 필요한 요소에 대해 간단하게 정리해 보았습니다.

임베디드 특징중에 타깃-하드웨어 병목현상(target-hardware bottleneck) 이 있는데 이를 줄이기 위해 계층을 나눠 서로 섞이지 않도록 경계를 잡아야 합니다.

프로세서도 세부사항이다. 마이크로 컨트롤러를 사용할때 펌웨어가 저수준 함수들을 프로세스 추상화 계층(Processor, Abstraction Layer, PAL)의 형태로 격리 시켜줄수 있습니다.

작성한 코드의 수명을 늘리려면, 운영체제에 의존하는 일을 막고 무조건 운영체제를 세부사항으로 취급해야합니다. 운영체제 추상화 계정(Operating System Abstrction Layer, OSAL) 을 통해 소프트웨어를 운영체제로부터 격리 시킵니다.

인터페이스를 통하고 대체 가능성을 높이는 방향으로 프로그래밍 해야합니다. 계층형 아키텍처(layered architecture)와 같이 인터페이스를 통해 프로그래밍하자는 발상을 기반으로 설계합니다.

DRY 원칙: 조건부 컴파일 지시자를 반복하지 말아야 합니다. #ifdef BOARD_V2 구문이 수천번 사용 되는 케이스를 생각해보면 됩니다.

임베디드 소프트웨어의 추상화 계층, 출처 : Clean Architecture

임베디드 소프트웨어를 개발하는 사람들은 임베디드 소프트웨어 바깥의 경험에서 많은것을 배울 수 있습니다.

모든 코드가 펌웨어가 되도록 내버려두면 제품이 오래 살아남을 수 없게되고, 타깃 하드웨어에서만 테스트 할 수 있는 제품도 마찬가지 입니다.

클린 임베디드 아키텍처는 제품이 장기간 생명력을 유지하는데 도움을 줍니다.

감사합니다.

Get to know us better! Join our official channels below.

Telegram(EN) : t.me/Humanscape KakaoTalk(KR) : open.kakao.com/o/gqbUQEM Website : humanscape.io Medium : medium.com/humanscape-ico Facebook : www.facebook.com/humanscape Twitter : twitter.com/Humanscape_io Reddit : https://www.reddit.com/r/Humanscape_official Bitcointalk announcement : https://bit.ly/2rVsP4T Email : support@humanscape.io

기업문화 엿볼 때, 더팀스

로그인

/