Est-ce une bonne idée de faire du TDD sur des composants de bas niveau?

J'envisage d'écrire un pilote de bas niveau ou des composants / noyaux de système d'exploitation.

Les gens d' osdev.org semblent penser que les éléments importants ne sont pas significativement testables de cette façon, mais j'ai lu quelques discussions où les gens pensaient différemment. J'ai regardé autour de moi, mais je n'ai pas trouvé d'exemples réels de TDD sur des composants de bas niveau.

Est-ce quelque chose que les gens font réellement, ou simplement quelque chose dont les gens parlent en théorie parce qu'il n'y a pas une bonne façon de le faire dans la pratique?

— Facture
source

Si seulement MS fournissait aux développeurs du noyau les "simulations du noyau" appropriées (ou quoi que ce soit), la pratique en question ne serait pas "imaginative", je pense.

— mlvljr

Bonjour @Bill - J'ai reformulé un peu votre question et j'ai voté pour la rouvrir. Si je l'ai trop changé par rapport à votre intention d'origine, n'hésitez pas à modifier davantage ou à revenir à la question :)

— Rachel

Dit la même chose de mon point de vue - pas de soucis

— Bill

Réponses:

Si vous interagissez avec ou contrôlez du matériel, il est difficile de le tester sans lui. Vous pouvez essayer d'émuler le matériel, mais c'est souvent plus difficile que d'écrire le pilote en premier lieu, donc vous finissez par ne pas savoir si le bogue est dans votre pilote ou votre émulateur.

— TMN
source

Et pourquoi ne pas tester l'émulateur alors? ;)

— mlvljr

@mlvljr: parce que les émulateurs ne sont pas la vraie chose. rien ne remplace un matériel réel.

— Paul Nathan

@mlvljr Vous devez également tester l'émulateur par rapport à du matériel réel, en utilisant des suites de tests créées pour tester les tests d'origine pendant ... attendez, où suis-je encore?

— Note à soi-même - pensez à un nom

Donc, vmware et autres ne peuvent pas être testés alors?

— mlvljr

@mlvljr: C'est un point valable, mais je pense que cela sort du domaine de "TDD". Peu de développeurs ont accès à un émulateur scriptable et instrumenté au niveau du système. J'ai eu de la chance d'avoir une portée à quatre canaux!

— TMN

Personnellement, j'ai tendance à croire que l'on peut bénéficier de nombreux avantages du TDD (sans réellement adhérer au TDD), en:

Écrite à l' appelant et l' appelé le code à la même époque (certainement pas plus de 24 heures d' intervalle).
- Et utilisez-le pour influencer la conception de l'interface (objets, appels de méthode et paramètres).
Pour un composant nécessitant un algorithme / code compliqué, pensez d'abord à l'implémenter dans un algorithme plus simple mais correct, même s'il est moins efficace (ou stupide, ou ne fonctionne que dans une situation plus étroite).
- Une méthode de test très simple consisterait à exécuter les deux algorithmes et à comparer leurs résultats.
Une fois qu'un bogue a été découvert (par quelque moyen que ce soit) dans une partie du code, cette partie du code mérite d'être testée de manière beaucoup plus agressive. Cela signifie faire des tests plus sophistiqués que TDD ne le préconiserait. (basé sur le raisonnement selon lequel les bogues se produisent dans les clusters )

TDD semble vous obliger à avoir une compréhension assez claire de la fonction que vous prévoyez d' implémenter ou des exigences que vous prévoyez de satisfaire en implémentant le code. Dans certaines situations, la compréhension du problème est tout simplement insuffisante. Cela aurait nécessité une solution Spike . Dans le cadre de cette solution Spike, TDD peut être appliqué car le problème a été réduit à un niveau gérable. Une fois que quelques pics ont été terminés, chacun couvrant certains aspects du problème d'origine, on peut commencer à travailler sur la solution complète, et appliquer TDD à ce stade pourrait être faisable en raison de la compréhension améliorée.

Édité:

Après avoir lu la page plus attentivement,

Bien qu'il devrait être possible de tester la plupart des fonctions du noyau dans un pilote de test "banc d'essai", les choses vraiment "juteuses" comme la gestion des interruptions, la répartition des processus ou la gestion de la mémoire ne sont probablement pas testables à l'unité. --- depuis http://wiki.osdev.org/Unit_Testing

Ils disent clairement que la plupart des pièces sont testables et que certaines pièces nécessitent un type de test différent: le test de résistance .

— rwong
source

cela implique également que les parties importantes sont les parties qui nécessitent différents tests à mon humble avis.

— Bill

quelle réponse impressionnante! à plusieurs niveaux, bravo!

— manuelBetancurt

Je ne. Dans le code intégré de mon maître, j'écris simplement le code et je passe mon temps à réfléchir à ce qu'il fait (et ce qu'il ne fait pas). Je ne suis pas sûr que cela puisse être fait dans mon cas de toute façon, je me rapproche étrangement de la limite physique de la mémoire sans injecter de code de test.

Je pense que pour les systèmes suffisamment volumineux (c'est-à-dire disposant de Mo de mémoire, pas de Ko), cela peut être fait pour certains composants si vous avez suffisamment de temps et d'efforts. Tester le code de lecture des broches en se moquant des broches n'est ... euh ... pas très significatif. Si vous avez suffisamment séparé votre logique, vous pouvez tester la logique ailleurs.

FWIW, je n'achète pas TDD dans le cas général - cela fonctionne très bien pour les piles système qui sont assez grandes avec suffisamment de ressources avec un comportement déterministe suffisant, en dehors de cela, cela ne semble pas une pratique raisonnable.

— Paul Nathan
source