Có phải là một ý tưởng tốt để làm TDD trên các thành phần cấp thấp?

Tôi đang xem xét việc viết trình điều khiển cấp thấp hoặc các thành phần / nhân hệ điều hành.

Các osdev.org folks dường như nghĩ rằng các bit quan trọng không có ý nghĩa kiểm chứng theo cách này, nhưng tôi đã đọc một số cuộc thảo luận mà mọi người nghĩ khác. Tôi đã nhìn xung quanh, nhưng không tìm thấy bất kỳ ví dụ thực tế nào về TDD trên các thành phần cấp thấp.

Đây có phải là điều mà mọi người thực sự làm, hay chỉ là điều mà mọi người nói về lý thuyết bởi vì không có cách nào tốt để làm điều đó trong thực tế?

Nếu bạn đang tương tác với hoặc kiểm soát phần cứng, thì thật khó để kiểm tra nếu không có nó. Bạn có thể thử mô phỏng phần cứng, nhưng điều đó thường khó hơn so với việc viết trình điều khiển ở nơi đầu tiên, vì vậy bạn sẽ không biết liệu lỗi trong trình điều khiển hay trình giả lập của mình.

Cá nhân tôi có xu hướng tin rằng một người có thể nhận được nhiều lợi ích của TDD (mà không thực sự tuân thủ TDD), bằng cách:

• Viết cả mã người gọi và mã callee cùng một lúc (chắc chắn cách nhau không quá 24 giờ).
  • Và sử dụng điều đó để ảnh hưởng đến thiết kế của giao diện (đối tượng, lời gọi phương thức và tham số).
• Đối với một thành phần yêu cầu một thuật toán / mã phức tạp, trước tiên hãy xem xét triển khai một thuật toán đơn giản nhưng chính xác hơn, ngay cả khi nó kém hiệu quả hơn (hoặc ngu ngốc hoặc chỉ hoạt động trong tình huống hẹp hơn).
  • Một phương pháp thử nghiệm rất đơn giản sẽ chạy cả hai thuật toán và so sánh kết quả của chúng.
• Khi một lỗi được phát hiện (bằng mọi cách) trong một phần của mã, phần mã đó xứng đáng được kiểm tra mạnh mẽ hơn nhiều. Điều này có nghĩa là thực hiện các bài kiểm tra phức tạp hơn TDD sẽ yêu cầu. (dựa trên lý do rằng lỗi xảy ra theo cụm )

TDD dường như yêu cầu bạn phải hiểu khá rõ về chức năng bạn dự định thực hiện hoặc yêu cầu nào bạn dự định đáp ứng bằng cách triển khai mã. Trong một số tình huống, đơn giản là có quá ít hiểu biết về vấn đề. Điều này sẽ kêu gọi một giải pháp Spike . Trong phạm vi của giải pháp Spike này, TDD có thể được áp dụng vì sự cố đã được thu hẹp xuống mức có thể quản lý được. Khi một vài Spike đã được hoàn thành, mỗi khía cạnh bao gồm một số khía cạnh của vấn đề ban đầu, người ta có thể bắt đầu làm việc với giải pháp đầy đủ và áp dụng TDD vào thời điểm đó có thể khả thi vì sự hiểu biết được cải thiện.

Đã chỉnh sửa:

Sau khi đọc trang cẩn thận hơn,

Mặc dù có thể kiểm tra hầu hết các chức năng hạt nhân trong trình điều khiển kiểm tra "đã kiểm tra", nhưng những thứ thực sự "ngon ngọt" như xử lý ngắt, gửi quá trình hoặc quản lý bộ nhớ có thể không kiểm tra được đơn vị. --- từ http://wiki.osdev.org/Unit_Testing

Họ rõ ràng nói rằng hầu hết các bộ phận đều có thể kiểm tra được và một số bộ phận yêu cầu một loại thử nghiệm khác: Thử nghiệm ứng suất .

Tôi không. Trong mã nhúng của Master tôi chỉ viết mã và dành thời gian suy luận về những gì nó làm (và không). Tôi không chắc nó có thể được thực hiện trong trường hợp của tôi không, tôi đang tiến gần đến giới hạn vật lý của bộ nhớ mà không cần tiêm mã kiểm tra.

Tôi nghĩ rằng đối với các hệ thống đủ lớn (tức là có MB bộ nhớ, không phải KB), nó có thể được thực hiện cho một số thành phần nếu bạn có đủ thời gian và công sức. Kiểm tra mã đọc mã pin bằng cách nhét các chân lên là ... er ... không có ý nghĩa lắm. Nếu bạn đã tách logic của mình đủ, bạn có thể kiểm tra logic ở nơi khác.

FWIW, tôi không mua TDD trong trường hợp chung - nó hoạt động tốt đối với các ngăn xếp hệ thống đủ lớn với đủ tài nguyên với đủ hành vi xác định, bên ngoài điều đó có vẻ không hợp lý.