로봇 (및 기타 기계 장치)에 대한 단위 테스트는 어떻게 작성합니까?

저는 고등학교 로봇 클럽 회원이며 로봇 프로그래밍을 책임지고 있습니다. 다양한 성인들로부터 계속해서 듣는 제안 중 하나는 코드를 검증하는 데 도움이되는 단위 테스트를 작성해야한다는 것입니다. 코드베이스가 조금 커지고 단위 테스트가 버그를 더 빨리 잡는 데 실제로 도움이 될 것이라는 데 동의합니다.

그러나 어떻게 이것을 달성 할 수 있는지 완전히 확신하지 못합니다. 내가 아는 한, 단위 테스트는 함수 (또는 코드의 하위 시스템)를 사용하여 매번 동일한 출력으로 나오도록 일련의 입력을 제공하여 수행됩니다. 현재 가지고있는 코드는 많은 양의 데이터 처리를 수행하지 않고 로봇의 하드웨어 구성 요소를 직접 조작합니다. 대부분의 복잡한 문제는 전자 장치의 사운드를 보장하고 현재 코드가 로봇의 실제 하드웨어와 일치하는지 확인하는 것입니다. 종종 로봇 자체에 코드를로드하여 문제가 있는지 확인할 수 있습니다. 그리고 그것을 실행하려고합니다.

또한 기계 장치를 작동시키기위한 코드에 대해 단위 테스트를 작성하는 방법은 무엇입니까? 기계의 작동을 물리적으로 관찰하여 오류 만 잡을 수있는 것 같습니다.

아니면 단위 테스트가 어떻게 작동하는지 오해하고 있습니까?

( 중요하다면, 코드 는 C ++로 작성되었으며 FRC에 참여하고 있습니다 )

이 테스트를 수행하려면 하드웨어 계층 을 조롱 해야합니다 . 아이디어는 코드가 실제 하드웨어와 통신하는 대신 제어 할 수있는 가짜 하드웨어 버전과 통신 한 다음 코드가 올바르게 작동하는지 확인하는 데 사용한다는 것입니다.

불행히도 극복해야 할 몇 가지 문제가 있습니다.

• 상대적으로 낮은 수준의 언어로 물건을 조롱하는 것이 더 어렵습니다 (따라서 훨씬 더 많은 작업)
• 하드웨어 수준의 물건을 조롱하는 것이 더 어렵습니다 (따라서 훨씬 더 많은 작업)

또한 자동화 된 단위 테스트의 가치의 대부분은 원래 코드를 작성한 후 오랜 시간 동안 회귀 버그를 포착하기 위해 언제든지 테스트를 실행할 수 있다는 데 있습니다. 이러한 종류의 경합에서는 경연이 끝난 후에는 코드가 전혀 사용되지 않으므로 테스트에서 대부분의 가치를 얻지 못할 수 있습니다. 특정 사례에 테스트를 추가하는 것이 얼마나 어려운지를 고려하면 수동 테스트를 수행하고 컨테스트의 기능에 집중하는 데 시간을 더 잘 사용하는 것이 좋습니다.

고려해야 할 몇 가지 사항을 생각할 수 있습니다. 첫 번째는 기본 래퍼 유형의 계층을 생성하더라도 하드웨어 액세스 계층을 가능한 한 얇게 만드는 것입니다. 이것은 몇 가지 장점을 제공합니다. 첫 번째는 하드웨어 액세스 자체에서 코드의 하드웨어 특정 동작을 분리 할 수 ​​있다는 것입니다. 즉, 하드웨어 자체에 액세스 할 필요없이 하드웨어 통신의 맨 아래까지 모든 것을 테스트 할 수 있습니다.

예를 들어, I2C 기반 신호 프로토콜을 설계해야하는 경우 하드웨어를 테스트에 연결하지 않고도 코드가 올바른 I2C 신호를 생성하는지 테스트 할 수 있습니다.

실제 하드웨어에 대한 호출의 경우 하드웨어 계층을 조롱하여 하드웨어가 올바르게 작동하는지 테스트 할 수 있습니다. 여기서 매우 얇은 하드웨어 계층을 유지하는 것이 실제로 비용을 절감 할 수 있습니다. 실제로 하드웨어를 처리하지만 모든 신호를 더 높은 수준에서 테스트 할 수 있어야하므로 개별 신호 자체를 테스트 할 필요는 없습니다. 즉, 신호를 하드웨어로 전송하는 특정 하드웨어 메서드에 대한 호출이 있는지 확인하기 위해 모의를 사용합니다. 하드웨어를 폴링해야하는 경우, 코드에서 이벤트 또는 메소드 만 트리거 할 수 있어야합니다. 리턴 신호는 다시 상위 계층에서 처리해야하기 때문입니다.

이것은 기본적으로 Oleksi가 자신의 말과 일치합니다 대답 일반적으로 하드웨어 수준의 물건을 조롱하는 것이 더 많은 작업이지만, 가능한 최소 코드 / 호출 계층을 유지할 수 있다면 그렇게 어렵지 않습니다. 하드웨어.

모든 테스트를 통과하는 코드가있는 경우 하드웨어 계층에서 모든 것을 올바르게 확인하려면 일련의 수동 테스트를 계속 수행해야합니다.

조롱과 레이어링을 제외하고 염두에 두어야 할 다른 것은 테스트 우선 개발 방법을 사용하는 것입니다. 기본적으로 요구 사항을 테스트 기준으로 코딩하고 구현을 테스트 기반으로합니다. 이를 통해 구현 코드를 최소로 유지하면서 모든 테스트 사례가 개발 노력을 주도하도록 할 수 있습니다. 중요하지 않은 다른 코드에 너무 많은 시간을 낭비하지 않으면 서 "그 이유만으로"유혹을 느끼게되므로 테스트를 통해 집중을 유지하고 디버깅 할 때 코드를 쉽게 변경할 수 있습니다. 단위 테스트 및 모의. 하드웨어를 통해 소프트웨어 버그를 디버깅하는 것은 매우 복잡하며 다른 작업에 더 많은 시간을 할애하는 데 많은 시간을 소비합니다.

나는 그들이 비행 시뮬레이터에서 어떻게하는지 말할 수 있습니다.

먼저, 프로그래머에게만이 질문을하면 응답의 절반 만 얻을 수 있으므로 http://electronics.stackexchange.com 에 교차 게시해야합니다 . 합니다.

로봇 작업은하지 않았지만 비행 시뮬레이터에서 하드웨어를 만드는 데 5 년을 보냈으므로 아키텍처 작동 방식을 알려줄 수 있습니다.

하드웨어 계층은 바보입니다

여기에는 간단한 입력 / 출력 값을 조정하고 아날로그 신호에 대한 보간 중단 점을 설정할 수있는 기본 인터페이스가 포함되어 있습니다. '신선한'하드웨어로 작업하는 경우 모든 보정이 거의 또는 전혀 필요없이 모든 것이 예상대로 작동하지만 시간이 지남에 따라 부품의 기계적 마모가 발생하여 조정해야합니다.

교정은 최소 / 최대 값 사이의 섹션이 포함 된 간단한 테이블입니다. 이들의 입력을 측정하기 위해 일반적으로 서보가 사용됩니다 (예 : 선형 전위차계, 변환기, 가속도계 등). 또는 계측의 경우 정확도를 시각적으로 판단하고 교정 될 때까지 조정하면됩니다.

소프트웨어 계층은 반대

모든 것이 복잡하고 상호 연결되어 있으므로 기능을 테스트하기 위해 일부 변수를 분리하는 것이 중요합니다. 데이터를 수집 할 수있는 현실적인 시나리오를 실행하는 것이 훨씬 쉽기 때문에 시나리오를 고민 할 필요가 없습니다. 테스트를 실행하면 기본적으로 저장된 데이터를 현재 출력과 비교하여 측정합니다.

비행 시뮬레이터에서는이를 QTG (자격 테스트 안내서)라고합니다. 핵심은 한 차원은 시간이고 다른 차원은 출력 인 2D 그리드에 데이터를 플로팅합니다.

믿거 나 말거나, 그것이 모델을 개발하는 방법의 본질입니다. 실제 비행기에는 수많은 센서가 장착되어 있으며 제어 된 시나리오를 수행합니다. 모든 컨트롤은 사람의 상호 작용없이 구동 될 수 있으므로 컴퓨터에서 테스트를 실행하고 (즉, 시뮬레이션 자체) 데이터를 비교합니다.

로봇 공학이 훨씬 다른 규모로 만들어 지더라도 원리는 동일합니다. 전통적인 접근 방식은 하드웨어와 소프트웨어 계층을 완전히 분리하여 둘 다 개별적으로 테스트 할 수 있도록하는 것입니다. 하드웨어 입력은 서보를 통해 수집되며 독립적 인 인터페이스를 통해 설정됩니다. Sofware 입력은 하드웨어로가는 신호를 독립적으로 측정하고 비교하여 알려진 '좋은'데이터에 대해 플로팅하여 설정 / 읽을 수 있습니다.

결과가 예측 가능하고 측정 가능하며 재현 가능한 한 테스트 자체가 반드시 복잡 할 필요는 없습니다.

앞에서 언급했듯이 하드웨어 부품을 조롱하고 스터브 아웃합니다. 예를 들어, 로봇에 대한 인터페이스가있는 경우 해당 인터페이스에서 상속 한 후 간단한 스텁 구현을 수행 할 수 있습니다. 그런 다음 스텁 구현이 예상대로 호출되었는지 테스트 할 수 있습니다. 예상되는 기능 또는 예상되는 매개 변수입니다.