테스트 주도 개발로 상태 머신 개발

상태 머신 모델은 임베디드 시스템에서 널리 사용되기 때문에 이 기사에서는 TDD(테스트 주도 개발) 접근 방식으로 상태 머신(SM) 소프트웨어를 개발하기 위한 몇 가지 전략을 살펴봅니다. 이 출판물은 기본 상태 머신 개념과 TDD 기술을 설명하는 것으로 시작합니다. 마지막으로 TDD 접근 방식을 사용하여 C로 작성된 상태 기계 소프트웨어를 개발하는 간단하고 순서가 지정된 방법을 소개합니다.

SM 모델은 상태, 전환 및 동작으로 구성됩니다. 상태는 시스템 또는 요소의 조건이지만 전환은 일반적으로 선행(소스) 상태를 후속(대상) 상태와 연결하는 관심 이벤트에 의해 시작되는 한 상태에서 다른 상태로의 경로입니다. 요소에 의해 실행되는 실제 동작은 액션으로 표현됩니다.

UML 상태 머신에서 작업은 상태 진입, 상태 종료, 전환 자체 또는 '내부 전환' 또는 '반응'이라고 하는 것과 관련될 수 있습니다. 모든 상태 머신의 형식론(UML 상태 머신 포함)은 일반적으로 상태 머신이 다음 이벤트 처리를 시작하기 전에 각 이벤트의 처리를 완료한다고 가정합니다. 이 실행 모델을 RTC(Run To Completion)라고 합니다. 이 모델에서 작업에는 시간이 걸릴 수 있지만 전체 종료 작업, 전환 작업 및 진입 작업 순서를 포함하여 상태 시스템이 완료될 때까지 보류 중인 이벤트는 기다려야 합니다.

TDD를 사용하여 상태 머신을 개발하는 전략을 다루기 전에 TDD의 정의, 중요성 및 적용을 언급할 가치가 있습니다.

먼저 TDD는 소프트웨어를 점진적으로 구축하는 기술입니다. 간단히 말해서, 먼저 실패한 단위 테스트를 작성하지 않고는 프로덕션 코드가 작성되지 않습니다. 테스트는 작습니다. 테스트가 자동화됩니다. 테스트 구동은 논리적입니다. 즉, 프로덕션 코드로 뛰어드는 대신(나중에 테스트를 위해 남겨둠) TDD 실무자는 테스트에서 원하는 코드 동작을 표현합니다. 테스트가 실패하면 TDD 실무자가 코드를 작성하여 테스트를 통과합니다. TDD 프로세스의 핵심에는 "TDD 마이크로사이클"이라는 짧은 단계로 구성된 반복 주기가 있습니다.

다음 목록의 TDD 주기 단계는 James Grenning의 '임베디드 C를 위한 테스트 주도 개발' 책을 기반으로 합니다.

• 작은 테스트를 추가합니다.
• 모든 테스트를 실행하고 새 테스트가 실패하면 컴파일조차 되지 않을 수 있습니다.
• 테스트를 통과하는 데 필요한 약간의 변경을 수행합니다.
• 모든 테스트를 실행하고 새 테스트가 통과하는지 확인합니다.
• 중복을 제거하고 표현력을 향상시키기 위해 리팩토링합니다.

그림 1의 다이어그램을 사용하여 TDD를 사용하여 상태 머신을 개발하는 더 간단한 방법을 찾아보겠습니다. 상태 머신이 초기화되면 StateA에서 시작됩니다. 상태. 알파를 받으면 이벤트가 발생하면 상태 시스템이 StateB로 전환됩니다. xStateA(), effect() 및 nStateB() 작업을 순서대로 실행하여 상태를 나타냅니다. 그렇다면 그림 1의 SM이 적절하게 작동하는지 확인하기 위해 어떻게 테스트할 수 있습니까?

그림 1. 기본 상태 머신(출처:VortexMakes)

그림 1과 같은 SM을 테스트하는 가장 전통적이고 간단한 방법은 주로 SMUT(State Machine Under Test)의 상태 전이 테이블을 확인하는 것입니다. 이렇게 하면 주별 테스트 사례가 됩니다. , 어떤 전환이 트리거되는지 확인하기 위해 관심 이벤트에 의해 SMUT가 자극됩니다. 동시에 이는 대상 상태와 실행된 각 전환에 대해 실행된 작업을 확인하는 것을 의미합니다. 액션이 충분히 복잡하다면 그에 대한 구체적인 테스트 케이스를 만드는 것이 더 적합합니다. (단위 테스트를 사용하여 상태 머신 테스트 문서에서 이 전략에 대해 자세히 설명합니다.)

모든 테스트 케이스는 xUnit 패턴에 따라 4개의 개별 단계로 나뉩니다.

• 설정 SM의 현재 상태(StateA)와 같은 테스트의 전제 조건을 설정합니다. ), 처리할 이벤트(알파 ) 및 전환 대상 상태인 예상 테스트 결과(StateB ) 및 실행할 작업의 정렬된 목록(xStateA(), effect() 및 nStateB()).
• 운동 알파로 상태 머신을 자극합니다. 이벤트.
• 확인 얻은 결과를 확인합니다.
• 정리 테스트 중인 상태 머신을 테스트 후 초기 상태로 되돌립니다. 선택 사항입니다.

위에서 언급한 전략은 TDD를 사용하여 SM을 개발하기에 충분합니다. 그러나 어떤 경우에는 기능을 확인하기 위해 하나 이상의 전환이 필요합니다. 이는 후속 전환의 일련의 작업으로 인해 효과가 표시되기 때문입니다. 즉, 기능에는 SMUT의 상태, 이벤트 및 전환 집합이 포함됩니다. 이러한 경우 격리된 상태 전환보다 완전하고 기능적인 시나리오를 테스트하는 것이 더 적절합니다. 결과적으로 테스트 케이스는 앞서 언급한 전략보다 더 기능적이고 덜 추상적입니다.

그림 2의 상태 머신을 사용하여 이 개념을 살펴보겠습니다.

그림 2. DoWhile 상태 머신(출처:VortexMakes)

그림 2는 'do-while' 루프와 유사한 실행 루프를 모델링하는 DoWhile이라는 상태 머신을 보여줍니다. DoWhile은 Yakindu Statechart Tool을 사용하여 그렸습니다. DoWhile이 생성될 때 'x =0' 및 'output =0' 액션이 호출되며 이러한 액션은 DoWhile의 모든 속성의 기본값을 설정합니다. 루프 반복 횟수는 'x++' 또는 'x =(x> 0) ? x–:x' 동작. 'i =0' 동작은 루프의 초기 조건을 설정합니다. 루프 본체는 루프 반복을 유지하는 'i++' 액션에 의해 실행되고, 종료 조건은 'i ==x' 가드를 통해 선택 의사 상태에 의해 평가됩니다. true이면 루프 본문이 다시 평가되는 식입니다. 종료 조건이 false가 되면 루프는 '출력 =i' 액션 실행을 종료합니다.

새로운 기능을 개발하기 전에 테스트 목록을 만드는 것이 좋습니다. 테스트 목록은 사양에서 파생되며 수행해야 하는 작업에 대한 최상의 비전을 정의합니다. 완벽할 필요는 없기 때문에 전자 목록은 나중에 수정할 수 있는 임시 문서일 뿐입니다. DoWhile의 초기 테스트 목록은 다음과 같습니다.

• SM 초기화 후 모든 데이터는 기본적으로 설정됩니다.
• X 속성 증가
• X 속성 감소
• 단일 반복 루프 실행 가능
• 다중 반복 루프 실행 가능
• 비반복 루프 실행 가능
• 범위를 벗어난 값 확인

DoWhile 상태 머신을 개발하기 위해 Ceedling과 Unity가 가장 간단하지만 명료한 프로그래밍 기술인 'switch-case' 문장의 사용과 함께 사용될 것입니다. Ceedling은 C 프로젝트에 대한 전체 테스트 및 빌드 환경을 생성하는 빌드 시스템입니다. Unity는 C 프로젝트를 위한 가볍고 휴대 가능한 표현형 C 언어 테스트 도구입니다.

두 개의 파일이 이 상태 시스템 DoWhile.h 및 DoWhile.c를 나타내므로 테스트 중인 소스 코드입니다. 코드 목록 1은 앞서 언급한 전략을 적용하여 위의 테스트 목록을 구현하는 test_DoWhile.c 파일의 일부를 보여줍니다. 이 기사를 간단하게 유지하기 위해 코드 목록 1은 test_SingleIteration()에 의해 구현되는 '단일 반복 루프를 실행할 수 있습니다'라는 테스트 사례만 보여줍니다. 코드와 모델 모두 https://github.com/leanfrancucci/sm-tdd.git 저장소에서 사용할 수 있습니다.

코드 목록 1:단일 반복 테스트(출처:VortexMakes)

이 테스트는 DoWhile이 한 번의 반복만 올바르게 실행할 수 있는지 확인합니다. 그렇게 하기 위해 test_SingleIteration()은 DoWhile_init()를 호출하여 DoWhile 상태 머신을 초기화합니다(96행). DoWhile 루프에서 실행할 0의 반복 횟수를 설정합니다. 그 후 DoWhile은 DoWhile_dispatch()를 호출하여 이벤트를 처리할 준비가 됩니다. 단일 반복을 실행하기 위해 test_SingleIteration()은 Up DoWhile에 대한 이벤트(97행). 이 이벤트는 반복 횟수를 1로 증가시킵니다. 테스트는 Start 를 전송하여 루프를 시작합니다. 이벤트(98행)가 발생하면 알파 DoWhile이 단일 반복을 실행하도록 이벤트입니다(99행). 이것은 out 속성의 값이 실행된 반복 횟수와 같은지 확인함으로써 확인됩니다(101행). 마지막으로 DoWhile은 StateC 에 남아 있어야 합니다. 상태(102행).

DoWhile이 둘 이상의 반복을 실행할 수 있음을 증명하기 위해 test_SingleIteration()이 코드 목록 2와 같이 확장됩니다.

코드 목록 2:다중 반복 테스트(출처:VortexMakes)

코드 목록 3에 표시된 test_NoneIteration() 테스트는 DoWhile이 Alpha 를 수신할 때 반복을 실행하지 않는지 확인합니다. 이전에 위로 를 통해 반복 횟수를 설정하지 않은 이벤트 이벤트.

코드 목록 3:비반복 테스트(출처:VortexMakes)

DoWhile의 구현 세부 정보가 이 기사의 목적은 아니지만 코드 목록 4 및 코드 목록 5는 DoWhile.c 및 DoWhile.h 파일의 일부를 보여줍니다. 이 파일은 실제로 C에서 'switch-case' 문장을 사용하여 DoWhile의 시범 구현을 나타냅니다.

코드 목록 4:DoWhile 구현의 일부(출처:VortexMakes)

코드 목록 5:DoWhile 사양의 일부(출처:VortexMakes)

위에 소개된 두 전략은 모두 소프트웨어 품질을 높이는 가장 중요한 접근 방식 중 하나인 TDD를 사용하여 상태 머신 소프트웨어를 개발하는 간단하고 순서 있는 방법을 제공합니다.

첫 번째 전략은 주로 SMUT의 상태 전이 테이블을 확인하는 것으로 구성됩니다. 이 방법은 주별 테스트 사례를 만듭니다. . 다른 전략은 완전하고 기능적인 시나리오에 대한 테스트 사례를 실현하는 것을 제안합니다. , 이는 종종 SMUT의 상태, 이벤트 및 동작 세트를 포함합니다. 이 두 번째 전략은 테스트를 첫 번째 전략보다 더 기능적이고 덜 추상적으로 만듭니다. 이러한 전략은 특정 종류의 시스템, 프로그래밍 언어 또는 도구와 무관하지만 임베디드 시스템에서 매우 유용합니다. 그 중 많은 전략이 일반적으로 하나 이상의 상태 머신에서 정의되는 상태 기반 동작을 가지고 있기 때문입니다.

C 언어는 임베디드 소프트웨어 개발에 가장 널리 사용되는 언어 중 하나이기 때문에 선택되었습니다. 그래서 해당 언어로 TDD를 적용하기 위해 Ceedling과 Unity를 선택했습니다. 결론적으로, 이러한 방법을 통해 개발자는 기존 접근 방식보다 훨씬 더 유연하고 유지 관리가 용이하며 재사용 가능한 소프트웨어를 더 간단하고 정렬된 방식으로 빌드할 수 있습니다.