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

Sto pensando di scrivere un driver di basso livello o componenti / kernel del sistema operativo.

La gente di osdev.org sembra pensare che i bit importanti non siano significativamente verificabili in questo modo, ma ho letto alcune discussioni in cui le persone la pensavano diversamente. Mi sono guardato intorno, ma non sono riuscito a trovare esempi di vita reale di TDD su componenti di basso livello.

È qualcosa che le persone fanno davvero, o solo qualcosa di cui le persone parlano in teoria perché non c'è un buon modo per farlo in pratica?

— Conto
fonte

Se solo MS fornisse agli sviluppatori del kernel appropriati "mock del kernel" (o qualunque cosa potesse essere), la pratica in questione non sarebbe così "fantasiosa", credo.

— mlvljr,

Ciao @Bill - Ho riformulato un po 'la tua domanda e ho votato per riaprirla. Se l'ho modificato troppo rispetto al tuo intento originale, non esitare a modificare ulteriormente o ripristinare la domanda :)

— Rachel

Dice la stessa cosa dal mio punto di vista - niente preoccupazioni

— Bill

Risposte:

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

— TMN
fonte

E allora perché non testare l'emulatore? ;)

— mlvljr

@mlvljr: perché gli emulatori non sono la cosa reale. non c'è sostituto per l'hardware reale.

— Paul Nathan,

@mlvljr Dovresti anche testare l'emulatore su hardware reale, usando le suite di test create per testare i test originali per ... aspetta, dove sono di nuovo?

— Nota per se stessi: pensa a un nome il

Quindi, vmware e simili non possono essere testati allora?

— mlvljr,

@mlvljr: è un punto valido, ma penso che esuli dal regno di "TDD". Non molti sviluppatori hanno accesso a un emulatore di livello di sistema strumentabile e programmabile. Mi sono sentito fortunato ad avere un ambito a quattro canali!

— TMN,

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

Scrittura sia il chiamante e il callee il codice a circa lo 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, prendere innanzitutto in considerazione 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 l'esecuzione di entrambi gli algoritmi e il confronto dei loro risultati.
Una volta scoperto un bug (con qualsiasi mezzo) in una parte del codice, quella parte del codice merita di essere testata in modo molto più aggressivo. Ciò significa eseguire test più sofisticati di quelli richiesti da TDD. (basato sul ragionamento che i bug si verificano nei cluster )

TDD sembra richiedere di avere una comprensione abbastanza chiara di quale funzione si intende implementare o quali requisiti si prevede di soddisfare implementando il codice. In alcune situazioni, c'è semplicemente troppo poca comprensione del problema. Ciò avrebbe richiesto una soluzione Spike . Nell'ambito di questa soluzione Spike, TDD può essere applicato perché il problema è stato ridotto a un livello gestibile. Una volta che sono stati completati alcuni picchi, ognuno dei quali copre alcuni aspetti del problema originale, si può 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,

Mentre dovrebbe essere possibile testare la maggior parte delle funzioni del kernel in un driver di test "testbed", le cose veramente "succose" come la gestione degli interrupt, l'invio di processi o la gestione della memoria non sono probabilmente testabili dall'unità. --- da http://wiki.osdev.org/Unit_Testing

Stanno chiaramente dicendo che la maggior parte delle parti sono testabili e che alcune parti richiedono un diverso tipo di test: stress test .

— rwong
fonte

implica anche che le parti importanti sono le parti che richiedono diversi imho di prova.

— Bill

che risposta fantastica! in alcuni livelli saluti!

— manuelBetancurt,

Io non. Nel codice incorporato del mio Master scrivo semplicemente il codice e dedico il mio tempo a ragionare su ciò che fa (e non). Non sono sicuro che si possa fare nel mio caso, mi sto avvicinando in modo inquietante al limite fisico della memoria senza iniettare il codice di test.

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

FWIW, non compro TDD nel caso generale - funziona benissimo per stack di sistema che sono abbastanza grandi con abbastanza risorse con un comportamento deterministico sufficiente, al di fuori di ciò non sembra una pratica ragionevole.

— Paul Nathan
fonte