Düşük seviyeli bileşenlerde TDD yapmak iyi bir fikir mi?

Düşük seviyeli bir sürücü veya işletim sistemi bileşenleri / çekirdekleri yazmayı düşünüyorum.

Osdev.org millet önemli bitleri anlamlı bu şekilde test edilebilir olmadığını düşünüyor ama insanlar farklı düşünce bazı tartışmalar okudum. Etrafa baktım, ancak düşük seviyeli bileşenlerde TDD'nin gerçek hayattan örneklerini bulamadım.

Bu insanların gerçekten yaptığı bir şey mi, yoksa sadece teorik olarak insanların konuştuğu bir şey mi, çünkü pratikte bunu yapmanın iyi bir yolu yok mu?

Donanımla etkileşime giriyor veya kontrol ediyorsanız, onsuz test etmek zordur. Donanımı taklit etmeyi deneyebilirsiniz, ancak bu genellikle ilk etapta sürücüyü yazmaktan daha zordur, bu nedenle hatanın sürücünüzde veya emülatörünüzde olup olmadığını bilmeden sarsarsınız.

Ben şahsen (aslında TDD bağlı kalmadan) TDD faydalarının birçoğu elde inanıyorum eğilimindedir, tarafından:

• Arayanın ve callee kodunun aynı anda yazılması (kesinlikle 24 saatten fazla olmamalıdır).
  • Ve bunu arayüzün tasarımını (nesneler, yöntem çağrıları ve parametreler) etkilemek için kullanın.
• Karmaşık bir algoritma / kod gerektiren bir bileşen için, daha az verimli olsa bile (veya aptalca veya sadece daha dar bir durumda çalışıyorsa bile) önce daha basit ama doğru bir algoritmayı uygulamayı düşünün.
  • Çok basit bir test yöntemi, her iki algoritmayı çalıştırmak ve sonuçlarını karşılaştırmak olacaktır.
• Kodun bir bölümünde (herhangi bir yolla) bir hata bulunduğunda, kodun bu kısmı çok daha agresif bir şekilde test edilmeyi hak eder. Bu, TDD'nin gerektirdiğinden daha karmaşık testler yapmak anlamına gelir. ( hataların kümelerde oluştuğu gerekçesine dayanarak )

TDD, hangi işlevi uygulamayı planladığınızı veya kodu uygulayarak hangi gereksinimleri karşılamayı planladığınızı oldukça net bir şekilde anlamanızı gerektiriyor gibi görünmektedir . Bazı durumlarda, sorunun çok az anlaşılması söz konusudur. Bu bir Spike çözümü gerektirirdi. Bu Spike çözümü kapsamında, sorun yönetilebilir bir seviyeye indirildiği için TDD uygulanabilir. Her biri orijinal sorunun bazı yönlerini kapsayan birkaç Spikes bittikten sonra, tam çözüm üzerinde çalışmaya başlanabilir ve bu noktada TDD'nin uygulanması, geliştirilmiş anlayış nedeniyle mümkün olabilir.

Düzenlendi:

Sayfayı daha dikkatli okuduktan sonra,

Çekirdek işlevlerinin çoğunu "testbed" test sürücüsünde test etmek mümkün olsa da, kesinti işleme, işlem gönderme veya bellek yönetimi gibi gerçekten "sulu" şeyler muhtemelen birim test edilemez. --- http://wiki.osdev.org/Unit_Testing adresinden

Çoğu parçanın test edilebilir olduğunu ve bazı parçaların farklı bir test türü gerektirdiğini açıkça söylüyorlar : Stres Testi .

Yapmıyorum. Efendimin gömülü kodunda sadece kodu yazıyorum ve zamanımı ne yaptığına (ve yapmadığına) dair akıl yürütüyorum. Zaten benim durumumda yapılabileceğinden emin değilim, test kodunu enjekte etmeden belleğin fiziksel sınırına rahatsız edici bir şekilde yaklaşıyorum.

Yeterince büyük sistemler için (yani KB değil, MB bellek var), yeterli zaman ve çaba varsa bazı bileşenler için yapılabilir düşünüyorum. Pimleri yukarı atarak pim okuma kodunu test etmek ... er ... çok anlamlı değil. Mantığınızı yeterince ayırdıysanız, mantığı başka bir yerde test edebilirsiniz.

FWIW, genel durumda TDD satın almıyorum - yeterli belirleyici davranışa sahip yeterli kaynaklara sahip yeterince büyük sistem yığınları için iyi çalışıyor, bunun dışında makul bir uygulama gibi görünmüyor.