L'interface utilisateur de test de conduite est problématique car vous ne savez souvent pas ce que vous voulez sur l'écran tant que vous ne le voyez pas à l'écran. Pour cette raison, le développement de l'interface graphique a tendance à être massivement itératif et donc très difficile à conduire avec des tests. Cela ne veut pas dire que nous abandonnons simplement TDD pour les interfaces graphiques. Au contraire, nous poussons autant de code que possible hors de l'interface graphique, ne laissant derrière que du code de câblage simple. Ce câblage nous permet de faire les changements massivement itératifs dont nous avons besoin, sans affecter l'essence du problème.
Cette technique a probablement été décrite par Michael Feathers il y a quelques années dans un article intitulé "The Humble Dialog Box". C'est aussi l'idée fondamentale derrière le modèle Model-View-Presenter qui a causé une telle agitation il y a quatre ans; et a maintenant été divisé en modèles Passive View et Supervision Controller. Le lien de l'article dans cette question profite de ces idées, mais d'une manière test-après plutôt que d'un test.
L'idée est de tester tout sauf la vue. En effet, nous n'avons même pas besoin d'écrire la vue depuis longtemps. En effet, le View est si simplement absurde qu'il n'a probablement pas besoin de tests unitaires. Ou si c'est le cas, ils peuvent en fait être écrits en dernier.
Pour tester le contrôleur de supervision, vous devez simplement vous assurer que vous comprenez comment les données seront présentées à l'écran. Vous n'avez pas besoin de savoir où sont les données, ni quelle est la police, ou de quelle couleur il s'agit, ni aucun des autres problèmes esthétiques qui provoquent l'itération massive des interfaces graphiques. Au contraire, vous savez qu'un élément de données sera une sorte de champ de texte. Un autre sera un menu, encore un autre sera un bouton ou une case à cocher. Ensuite, vous vous assurez que la vue peut poser toutes les questions dont elle a besoin pour obtenir ces éléments correctement.
Par exemple, la zone de texte peut avoir une valeur par défaut. La vue devrait pouvoir le demander. Le menu peut avoir des éléments grisés. La vue devrait pouvoir demander cette information. Les questions posées par la vue concernent toutes la présentation et sont dépourvues de règles métier. Du même coup, la vue indiquera au contrôleur de supervision quand quelque chose change. Le contrôleur modifiera les données de manière appropriée, y compris tout type de validation et de récupération d'erreur, puis la vue pourra demander comment ces données doivent être présentées.
Tout cela peut être piloté par le test car tout est découplé de l'affichage visuel. C'est tout sur comment les données sont manipulées et présentées, et pas à propos de quoi il ressemble. Il n'a donc pas besoin d'être massivement itéré.