05 아키텍처 - 6

28장 테스트 경계

 

 

시스템 컴포넌트인 테스트

테스트의 의존성은 항상 테스트 대상이 되는 시스템의 컴포넌트를 향함.

역할은 운영이 아니라 개발은 지원하는 것.

모든 시스템 컴포넌트가 지켜야하는 모델을 표현해 줌.

 

테스트를 고려한 설계

시스템에 결합된 테스트는 시스템이 변경될 때 같이 변경되야함.

공통 컴포너트가 변경되면  Fragile Tests Problem 이 생김.

문제를 해결하려면 테스트를 고려해서 설계해야 함.

                                                                                                                                                                                                            변동성이 있는것에 의존하지 말라

- 업무규직을 테스트할 수 있게.                                                                                                                                                                                                                                                                                                                                                                          

테스트 API

테스트가 모든 업무규칙을 검증하는데 사용할 수 있도록 특화 API를 만듬.

시스템을 테스트 가능한 특정 상태로 강제하는 힘.

API는 인터랙터 Interactor 와 인터페이스 어댑터 Interface Adaptor 들의 상위집합.

테스트 구조를 애플리케이션 구조로부터 결합을 분리하는게 목표.

 

구조적 결합

테스트 결합 중 가장 강력.

테스트 API역학은 애플리케이션 구조를 테스트로부터 숨김.

상용코드나 테스트를 리팩터링할때도 서로 영향을 주지 않게함.

 

보안

테스트 API는 독립적으로 배포할 수 있는 컴포넌트로 분리.

 

결론

테스트는 시스템의 일부이므로 잘 설계되어야 함.

 

---

29장 클린 임베디드 아키텍처

 

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

 

코드에 SQL을 심거나 토드 전반에 플랫폼 의존성을 만든다면 엔지니어 또한 펌웨어를 작성하는것과 같음.

소프트웨어가 하드웨어로부터 분리될 필요성.

 

앱-티튜드 테스트 App-titude test

켄트벡 소프트웨어 구축

• 먼저 동작하게 만들어라
• 올바르게 만들어라
  리펙터링해 코드를 개선
• 빠르게 만들어라
  리팩터링해 요구되는 성능을 만족시킴.

앱이 동작하도록 만드는 것 - 개발자용 앱티튜드 테스트

 

타깃-하드웨어 병목현상

임베디드가 지닌 특수한 문제.

타깃이 테스트가 가능한 유일한 장소이면 타깃-하드웨어 병목현상이 발생해 문제.

 

클린 임베디드 아키텍처는 테스트하기 쉬운 임베디드 아키텍처다.

 

- 계층

세개의 계층

하드웨어와 나머지 시스템 사이 분리.

하드웨어 정보가 코드 전체를 오염시키지 못하게.

소프트웨어와 펌웨어가 섞이는 안티패턴은 변화에 취약.

 

- 하드웨어는 세부사항이다

소프트웨어와 펌웨어 사이 경계(하드웨어 추상화 계층 Hardware Abstraction Layer HAL)는 코드와 하드웨서 경계와 달리 정의하기 힘듬.

이 경계를 분명하게 해야함.

HAL은 자신보다 웨이 있는 소프트웨어를 위해 존재.

HAL의 API는 소프트웨어의 필요에 맞게 만들어져야 함.

 

HAL 사용자에게 하드웨어 세부사항을 드러내지 말라

 

HAL은 타깃에 상관없이 테스트 할 수 있는 경계층, 일련의 대체지점 제공.

 

- 프로세서는 세부사항이다

임베디드 애플리케이션이 특수한 툴 체인을 사용하고 이런 툴 체인의 컴파일러는

업체의 프로세서 기능에 접근할 수 있는 새로운 기능에 접근할 수 있는 새로운 키워드를 제공함.

 

#ifndef _ACME_STD_TYPES
#define _ACME_STD_TYPES

#if defined(_ACME_X42)
    typedef unsigned int    Uint_32;
    typedef unsigned short  Uint_16;
    typedef unsigned char   Uint_8;
    
    typedef int             Int_32;
    typedef short           Int_16; 
    typedef char            Int_8;
    
#elif defined(_ACME_A42)
    typedef unsigned long  Uint_32;
    typedef unsigned int   Uint_16;
    typedef unsigned char  Uint_8;
    
    typedef long           Int_32;
    typedef int            Int_16;
    typedef char           Int_8;

#else
    #error <acmetypes.h> is not supported for this environment
#endif

#endif

 

헤더파일을 직접사용하면 코드가 종속됨. 

_ACME_X42 나 _ACME_A42 를 정의하면 타깃이 아닌 하드웨어 코드를 테스틓라 때 정수 변수가 잘못된 크기를 가짐.

이식성을 고려하지 않고 헤더를 사용하는 파일을 소수로 제한하지 않는다면 이식작업이 어려워짐.

 

클린 임베디드 아키텍처는 장치 접근 레지스터를 직접 사용하는 코드는 소수의 펌웨어로만 한정.

펌웨어가 저수준 함수들을 프로세서 추상화 계층PAL의 형태로 격리하면,

PAL 상위 위치하는 펌웨어는 타깃-하드웨어에 관계없이 테스트 가능.

 

- 운영체제는 세부사항이다.

베어메탈 bare-metal (운영체제가 없는 임베디드 시스템) 이라면 HAL로 충분.

임베디드 시스템에서 실시간 운영체제RTOS 를 쓴다면 운영체제를 세부사항으로 취급하고 의존하지 말아야 함.

 

운영체제 추상화 계층 Operating System Abstraction Layer, OSAL 을 통해 소프트웨어를 운영체제로부터 격리.

 

인터페이스를 통하고 대체 가능성을 높이는 방향으로 프로그래밍 하라

관심사를 분리시키고, 인터페이스를 활용해 대체가능성을 높이는 방향으로 프로그래밍.

 

모듈들이 인터페이스를 통해 상호작용해 특정 서비스 제공자를 다른것으로 대체 가능하도록.

 

헤더파일에는 함수선언과 함수에서 사용하는 상수, 구조체 이름만 포함 시키고, 

구현체에서만 필요한 정의사항들은 제외하자.

 

DRY 원칙: 조건부 컴파일 지시자를 반복하지 말라.

 

코드 반복을 반복하지 말라 Don't Repeat Yourself. DRY 원칙.

HAL 이 조건부 컴파일 대신 사용할 수 있는 일련의 인터페이스를 제공하고,

링커, 실시간 바인딩을 사용해 소프트웨어와 하드웨어를 연결.

결론

모든 코드가 펌웨어가 되도록 하면 제품이 오래 살아남지 못함.