Tôi có thể sử dụng khung kiểm tra đơn vị nào cho dự án mcu dựa trên ac?


15

Tôi đang suy nghĩ về cách tôi có thể sử dụng các bài kiểm tra đơn vị trong dự án mcu của mình và tôi có thể sử dụng các khung công tác nào để đơn giản hóa nó.

Hôm nay tôi đang sử dụng stm32 với OpenOCD-jtag từ máy tính Linux, nơi tất cả được điều khiển từ Makefile cổ điển và được biên dịch chéo với gcc.

Tôi có thể tự tạo ra một cái gì đó, nhưng nếu có một khung mà tôi có thể sử dụng thì nó sẽ rất tuyệt. (Đó là phần thưởng nếu khung có thể xuất kết quả theo định dạng mà Jenkins / Hudson có thể đọc).

Có cách nào để sử dụng khung kiểm tra đơn vị với stm32 không?


3
Tôi không có thời gian để viết một câu trả lời đầy đủ, nhưng tôi đã sử dụng rất nhiều công cụ và kỹ thuật được tìm thấy trong các bài báoloạt blog này . Trong một từ: CMock!
Kevin Vermeer

Câu trả lời:


4

Hãy xem CppUTest và http://pragprog.com/book/jgade/test-driven-development-for-embedded-c của James Grenning

CppUTest có hỗ trợ cho C và C ++ và nó có một bộ các mẫu Makefile tuyệt vời giúp tôi bắt đầu khá nhanh.


Mua phiên bản ePub, hãy xem nó có tốt không :)
Johan

Cuốn sách rất hay, nhưng tôi nghĩ rằng sự thống nhất (khuôn khổ khác trong cuốn sách đó) sẽ đáp ứng nhu cầu của tôi tốt hơn.
Johan

Được chấp nhận từ khi cuốn sách đẩy tôi đi đúng hướng.
Johan

5

Có rất nhiều biến số sẽ xác định khung thử nghiệm đơn vị tốt nhất để sử dụng trong tình huống của bạn. Một số mặt hàng có thể ảnh hưởng đến sự lựa chọn của bạn sẽ là:

  • Ngôn ngữ đích.
  • Những gì hỗ trợ thư viện có sẵn. ví dụ libc hoặc phiên bản cắt giảm của chúng.
  • Hệ điều hành của mục tiêu. ví dụ: Không, FreeRTOS, tùy chỉnh.

Hầu hết các khung loại xUnit sẽ cung cấp một số mức chức năng cơ bản có thể hữu ích. Tôi đã sử dụng Cunit với một số thành công trong quá khứ. (gói libcunit1-dev trên Ubuntu / Debian). Hầu hết các khung sẽ yêu cầu libc có sẵn, một số sẽ yêu cầu hỗ trợ hệ điều hành bổ sung.

Một thay thế khác chỉ dài 3 dòng là Minunit .

Tôi đã tìm thấy thử nghiệm đơn vị bằng cách sử dụng vi điều khiển làm mục tiêu khá cồng kềnh vì bạn cần có khả năng trình bày một môi trường phù hợp để tải xuống các thử nghiệm, chạy chúng và sau đó lấy lại kết quả. Chỉ cần có được nền tảng tại chỗ sẽ cho phép bạn làm điều này là một nhiệm vụ lớn.

Một cách tiếp cận khác mà tôi đã thực hiện cho tôi là thử nghiệm đơn vị trên máy chủ, thực hiện lớp trừu tượng giữa trình điều khiển và mã ứng dụng. Vì bạn đang sử dụng gcc cho mục tiêu, mã cũng sẽ được biên dịch trên máy chủ.

Việc kiểm tra trên máy chủ biên dịch nói chung dễ dàng hơn nhiều khi bạn có sự hỗ trợ đầy đủ của HĐH máy chủ và tất cả các công cụ của nó. Ví dụ: khi kiểm tra trên máy chủ, tôi có một phiên bản trình điều khiển không dây bị chế giễu với giao diện giống như trình điều khiển thực chạy trên mục tiêu. Phiên bản máy chủ sử dụng các gói UDP để mô phỏng chuyển gói không dây, với trình điều khiển giả hỗ trợ khả năng bỏ gói để tôi có thể kiểm tra các giao thức của mình.

Trong sản phẩm tôi đang làm việc, một hệ điều hành có luồng đang được sử dụng, do đó, lớp trừu tượng để thử nghiệm trên hệ điều hành máy chủ đã sử dụng pthreads thay thế.

Mặc dù không hoàn hảo, bạn càng dễ dàng viết và chạy thử nghiệm, bạn càng có nhiều khả năng thực hiện nhiều trường hợp thử nghiệm hơn. Một lợi ích khác của việc chạy mã trên các nền tảng khác nhau là kiểm tra xem mã có khả dụng không. Bạn sẽ nhanh chóng nhận ra những sai lầm về cuối nếu kiến ​​trúc mục tiêu và máy chủ khác nhau.

Bây giờ tôi hơi lạc đề, nhưng cảm thấy những ý tưởng này có thể giúp bạn lựa chọn khung kiểm tra và phương pháp kiểm tra.


Tôi đã giải quyết làm thế nào tôi nhận được mã trên mục tiêu và tôi có thể sử dụng gdb trong chế độ tập lệnh để dừng ở các điểm dừng khác nhau như test_ok hoặc test_fail ( fun-tech.se/stm32/TestSuite/index.php ). Vì vậy, tôi là loại một nửa. Đây là một câu hỏi làm thế nào để xây dựng các "bài kiểm tra" khác nhau. Ý tưởng của tôi hôm nay là một chút không thể tin được, đó là lý do tại sao tôi bắt đầu tìm kiếm một số loại khung.
Johan

1

Hãy xem embUnit http://embunit.sourceforge.net/embunit/index.html . Nó là một khung kiểm tra đơn vị C được nhúng với dấu chân thấp.

Chúng tôi đã sử dụng thành công nó trong một vài dự án vi điều khiển nhúng. Đừng mong đợi các tùy chọn và tính năng bạn nhận được với khung kiểm tra đơn vị máy tính để bàn. Nhưng nó chắc chắn đủ mạnh.

Nó có phân bổ các xác nhận được xác định cho bạn, vì vậy bạn không phải mất thời gian viết các xác nhận tùy chỉnh như với minUnit.


1

Cách đây một thời gian, tôi đã viết một hướng dẫn kỹ lưỡng về chủ đề: Các ứng dụng C kiểm thử đơn vị (nhúng) với Ceedling ; Tôi sử dụng các kỹ thuật này trong một loạt các dự án và cho đến nay tôi khá hạnh phúc.


2
Đây là một câu trả lời chỉ liên kết và như vậy sẽ trở nên vô giá trị nếu URL thay đổi hoặc liên kết bị hỏng. Bạn nên giải thích các thông tin liên quan trong câu trả lời , sau đó bạn có thể thêm liên kết làm tài liệu tham khảo.
ống

2
@pipe Có, nhưng câu hỏi (đề xuất sản phẩm về cơ bản) xin câu trả lời như thế này.
Dmitry Grigoryev


-1

Hãy thử lint, nhưng tôi không nghĩ rằng nó để thử nghiệm đơn vị, nó để phân tích mã.


2
Phân tích mã tĩnh không thể giúp thực thi và kiểm tra mã, do đó, nó không thực sự hữu ích.
Johan

1
Có lẽ không hữu ích trong bối cảnh thử nghiệm đơn vị, nhưng mọi người nên sử dụng một số loại công cụ phân tích tĩnh.
Tim
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.