Apakah itu ide yang baik untuk melakukan TDD pada komponen tingkat rendah?

Saya sedang mempertimbangkan untuk menulis driver level rendah atau komponen OS / kernel.

Orang- orang osdev.org tampaknya berpikir bahwa bit-bit penting tidak dapat diuji secara bermakna dengan cara ini, tetapi saya telah membaca beberapa diskusi di mana orang-orang berpikir secara berbeda. Saya telah melihat-lihat, tetapi gagal menemukan contoh nyata dari TDD pada komponen tingkat rendah.

Apakah ini sesuatu yang sebenarnya dilakukan orang, atau hanya sesuatu yang dibicarakan orang dalam teori karena tidak ada cara yang baik untuk melakukannya dalam praktik?

Jika Anda berinteraksi dengan atau mengendalikan perangkat keras, maka sulit untuk menguji tanpa itu. Anda dapat mencoba meniru perangkat keras, tetapi itu seringkali lebih sulit daripada menulis driver, jadi Anda akhirnya tidak tahu apakah bug ada di driver atau emulator Anda.

Saya pribadi cenderung percaya bahwa seseorang dapat memperoleh banyak manfaat dari TDD (tanpa benar-benar mematuhi TDD), dengan:

• Menulis kedua penelepon dan kode callee di sekitar waktu yang sama (pasti tidak lebih dari 24 jam terpisah).
  • Dan menggunakannya untuk mempengaruhi desain antarmuka (objek, pemanggilan metode dan parameter).
• Untuk komponen yang membutuhkan algoritme / kode yang rumit, pertimbangkan penerapan terlebih dahulu dalam algoritme yang lebih sederhana namun benar, meskipun kurang efisien (atau bodoh, atau hanya berfungsi dalam situasi yang lebih sempit).
  • Metode pengujian yang sangat sederhana akan menjalankan kedua algoritma dan membandingkan hasilnya.
• Begitu bug ditemukan (dengan cara apa pun) di salah satu bagian kode, bagian kode itu layak diuji lebih agresif. Ini berarti melakukan tes yang lebih canggih daripada TDD. (berdasarkan alasan bahwa bug terjadi dalam kelompok )

TDD tampaknya mengharuskan Anda untuk memiliki pemahaman yang cukup jelas tentang fungsi apa yang Anda rencanakan untuk implementasikan, atau persyaratan apa yang Anda rencanakan untuk dipenuhi dengan mengimplementasikan kode. Dalam beberapa situasi, hanya ada sedikit pemahaman tentang masalahnya. Ini akan membutuhkan solusi Spike . Dalam ruang lingkup solusi Spike ini, TDD dapat diterapkan karena masalahnya telah dipersempit ke tingkat yang dapat dikelola. Setelah beberapa Spike selesai, masing-masing mencakup beberapa aspek dari masalah asli, seseorang dapat mulai bekerja pada solusi lengkap, dan menerapkan TDD pada titik itu mungkin layak karena peningkatan pemahaman.

Diedit:

Setelah membaca halaman lebih hati-hati,

Walaupun mungkin untuk menguji sebagian besar fungsi kernel dalam driver test "testbed", hal-hal yang benar-benar "juicy" seperti penanganan interupsi, pengiriman proses atau manajemen memori mungkin tidak dapat diuji unit. --- dari http://wiki.osdev.org/Unit_Testing

Mereka jelas mengatakan bahwa sebagian besar dapat diuji, dan bahwa beberapa bagian memerlukan jenis pengujian yang berbeda: Pengujian Stres .

Bukan saya. Dalam kode tertanam Guru saya, saya hanya menulis kode dan menghabiskan waktu untuk berpikir tentang apa yang dilakukannya (dan tidak). Saya tidak yakin itu bisa dilakukan dalam kasus saya, saya semakin mendekati batas fisik memori tanpa menyuntikkan kode pengujian.

Saya pikir untuk sistem yang cukup besar (mis. Memiliki memori MB, bukan KB), itu bisa dilakukan untuk beberapa komponen jika Anda punya cukup waktu dan tenaga. Menguji kode membaca pin dengan mengolok-olok pin adalah ... er ... tidak terlalu berarti. Jika Anda sudah cukup memisahkan logika Anda, Anda dapat menguji logika di tempat lain.

FWIW, saya tidak membeli TDD dalam kasus umum - ini berfungsi dengan baik untuk tumpukan sistem yang cukup besar dengan sumber daya yang cukup dengan perilaku deterministik yang cukup, di luar itu tampaknya bukan praktik yang masuk akal.