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?

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.

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 .

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.