0. Écoutez vos programmeurs.
S'ils n'exécutent pas les tests, cela signifie qu'ils perçoivent que le coût (attendre l'exécution des tests, gérer les faux échecs) est supérieur à la valeur (détecter immédiatement les bugs). Diminuez les coûts, augmentez la valeur et les utilisateurs exécuteront les tests tout le temps.
1. Rendez vos tests 100% fiables.
Si vous avez des tests qui échouent avec de faux négatifs, résolvez-le immédiatement. Corrigez-les, changez-les, éliminez-les, de manière à garantir une fiabilité à 100%. (Il est correct d'avoir un ensemble de tests peu fiables, mais utiles, que vous pouvez exécuter séparément, mais le corps principal des tests doit être fiable.)
2. Modifiez vos systèmes pour garantir que tous les tests passent avec succès.
Utilisez des systèmes d'intégration continue pour vous assurer que seuls les commits passants sont fusionnés dans la branche principale / officielle / version / quelle que soit.
3. Changez votre culture pour valoriser à 100% les tests.
Apprenez à la leçon qu'une tâche n'est pas "terminée" jusqu'à ce que 100% des tests soient réussis et qu'elle ait été fusionnée dans la branche principale / officielle / de la version / quelle que soit leur origine.
4. Faites les tests rapidement.
J'ai travaillé sur des projets où les tests prennent une seconde, et sur des projets où ils durent toute la journée. Il existe une forte corrélation entre le temps nécessaire pour exécuter des tests et ma productivité.
Plus les tests sont longs, moins vous les exécutez souvent. Cela signifie que vous irez plus longtemps sans recevoir de commentaires sur les modifications que vous apportez. Cela signifie également que vous passerez plus de temps entre les commits. S'engager plus souvent signifie de plus petites étapes qui sont plus faciles à fusionner; engager l'histoire est plus facile à suivre; trouver un bug dans l'historique est plus facile; Il est également plus facile de revenir en arrière.
Imaginez des tests qui fonctionnent si vite que cela ne vous dérange pas de les exécuter automatiquement chaque fois que vous compilez.
Faire des tests rapidement peut être difficile (c'est ce que le PO a demandé, non!). Le découplage est la clé. Les imitations / faux sont acceptables, mais je pense que vous pouvez faire mieux en procédant à une refactorisation afin de les rendre superflus. Voir le blog d'Arlo Belshee, commençant par http://arlobelshee.com/post/the-no-mocks-book .
5. Faites des tests utiles.
Si les tests n'échouent pas lorsque vous vous trompez, alors à quoi ça sert? Apprenez-vous à écrire des tests qui détecteront les bugs que vous êtes susceptible de créer. Ceci est une compétence en soi, et prendra beaucoup d'attention.