È una buona idea fare TDD su componenti di basso livello?

Se stai interagendo o controllando l'hardware, è difficile testarlo senza. Puoi provare a emulare l'hardware, ma spesso è più difficile che scrivere il driver in primo luogo, così finisci per non sapere se il bug è presente nel tuo driver o nel tuo emulatore.

Personalmente tendo a credere che si possano ottenere molti dei benefici del TDD (senza aderire effettivamente al TDD), di:

• Scrittura del chiamante e del codice callee intorno allo stesso tempo (sicuramente non più di 24 ore di distanza).
  • E usalo per influenzare il design dell'interfaccia (oggetti, chiamate di metodo e parametri).
• Per un componente che richiede un algoritmo / codice complicato, considera innanzitutto l'implementazione in un algoritmo più semplice ma corretto, anche se è meno efficiente (o stupido, o funziona solo in una situazione più ristretta).
  • Un metodo di test molto semplice sarebbe eseguire entrambi gli algoritmi e confrontare i loro risultati.
• Una volta che un bug è stato scoperto (con qualsiasi mezzo) in una parte del codice, quella parte di codice merita di essere testata in modo molto più aggressivo. Questo significa fare test più sofisticati di quelli richiesti da TDD. (basato sul ragionamento che i bug si verificano nei cluster )

TDD sembra richiedere di avere una chiara comprensione di quale funzione pianifichi di implementare, o quali requisiti pianifichi di soddisfare implementando il codice. In alcune situazioni, c'è semplicemente troppa poca comprensione del problema. Ciò avrebbe richiesto una soluzione Spike . Nell'ambito di questa soluzione di Spike, TDD può essere applicato perché il problema è stato ridotto a un livello gestibile. Dopo aver completato alcuni Picchi, ognuno dei quali copre alcuni aspetti del problema originale, è possibile iniziare a lavorare sulla soluzione completa e applicare TDD a quel punto potrebbe essere fattibile a causa della migliore comprensione.

Modificato:

Dopo aver letto la pagina con più attenzione,

While it should be possible to test most kernel functions in a "testbed" test driver, the really "juicy" stuff like interrupt handling, process dispatching or memory management are probably not unit-testable. --- from http://wiki.osdev.org/Unit_Testing

Dicono chiaramente che la maggior parte delle parti sono testabili e che alcune parti richiedono un diverso tipo di test: Stress Test .

Non lo so. Nel codice incorporato del mio master scrivo il codice e passo il mio tempo a ragionare su cosa fa (e cosa no). Non sono sicuro che potrebbe essere fatto nel mio caso comunque, sto diventando fastidiosamente vicino al limite fisico della memoria senza iniettare il codice di test.

Penso che per i sistemi sufficientemente grandi (ovvero dotati di memoria MB, non KB), è possibile farlo per alcuni componenti se si dispone di tempo e sforzi sufficienti. Testare il codice pin-pin prendendo in giro i pin up è ... ehm ... non molto significativo. Se hai separato abbastanza la tua logica, puoi testare la logica altrove.

FWIW, non compro TDD nel caso generale - funziona bene per stack di sistema sufficientemente grandi con risorse sufficienti con un comportamento deterministico sufficiente, al di fuori di questo non sembra una pratica ragionevole.