Devrais-je avoir des tests unitaires pour les défauts connus?

Si mon code contient un défaut connu qui devrait être corrigé, mais ne l’est pas encore, et ne le sera pas pour la version actuelle, et pourrait ne pas l'être dans un avenir prévisible, en cas d'échec du test d'unité pour ce bogue dans la suite de tests? Si j'ajoute le test unitaire, il va (évidemment) échouer et s'habituer à l'échec des tests semble être une mauvaise idée. D'un autre côté, s'il s'agit d'un défaut connu et qu'un cas d'échec est connu, il semble étrange de le garder en dehors de la suite de tests, car il devrait être corrigé à un moment donné, et le test est déjà disponible.

La réponse est oui, vous devriez les écrire et les exécuter.

Votre infrastructure de test nécessite une catégorie de "tests ayant échoué connus" et vous devez marquer ces tests comme relevant de cette catégorie. Comment vous faites cela dépend du cadre.

Curieusement, un test qui échoue soudainement peut être tout aussi intéressant qu'un test réussi qui échoue de manière inattendue.

Je pense que vous devriez avoir un test unitaire avec le comportement actuel et dans les commentaires, ajouter le bon test et le bon comportement. Exemple:

@Test
public void test() {
  // this is wrong, it should be fixed some time
  Assert.assertEquals(2, new Calculator().plus(2,2));
  // this is the expected behaviour, replace the above test when the fix is available
  // Assert.assertEquals(4, new Calculator().plus(2, 2));
}

De cette façon, lorsque le correctif est disponible, la construction échouera, en remarquant le test ayant échoué. Lorsque vous regarderez le test, vous saurez que vous avez changé le comportement et que le test doit être mis à jour.

EDIT: Comme le dit Captain Man, dans les grands projets, cela ne sera pas réglé de si tôt, mais pour des raisons de documentation, la réponse originale est meilleure que rien.

Une meilleure façon de le faire est de dupliquer le test actuel, en faisant en sorte que le clone affirme la bonne chose et @Ignorequ’il contienne un message, par exemple:

@Test
public void test() {
  Assert.assertEquals(2, new Calculator().plus(2,2));
}

@Ignore("fix me, Calculator is giving the wrong result, see ticket BUG-12345 and delete #test() when fixed")
@Test
public void fixMe() {
  Assert.assertEquals(4, new Calculator().plus(2, 2));
}

Cela vient avec la convention dans votre équipe pour réduire le nombre de @Ignoretests d. Comme vous le feriez avec l'introduction ou la modification du test afin de refléter le bogue, sauf que vous n'échouerez pas la construction si cela est essentiel pour votre équipe, comme OP a dit que le correctif ne sera pas inclus dans la version actuelle. .

Selon l’outil de test, vous pouvez utiliser une fonction omitou pend.

Exemple en rubis:

gem 'test-unit', '>= 2.1.1'
require 'test/unit'

MYVERSION = '0.9.0' #Version of the class you test 


class Test_omit < Test::Unit::TestCase
  def test_omit
    omit('The following assertion fails - it will be corrected in the next release')
    assert_equal(1,2)
  end

  def test_omit_if
    omit_if(MYVERSION < '1.0.0', "Test skipped for version #{MYVERSION}")
    assert_equal(1,2)
  end

end

La omitcommande ignore un test, l' omit_ifassocie à un test. Dans mon exemple, je teste le numéro de version et n'exécute le test que pour les versions où l'erreur doit être résolue.

La sortie de mon exemple est:

Loaded suite test
Started
O
===============================================================================
The following assertion fails - it will be corrected in the next release [test_omit(Test_omit)]
test.rb:10:in `test_omit'
===============================================================================
O
===============================================================================
Test skipped for version 0.9.0 [test_omit_if(Test_omit)]
test.rb:15:in `test_omit_if'
===============================================================================


Finished in 0.0 seconds.

2 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications
0% passed

Donc ma réponse: oui, implémente le test. Mais ne confondez pas un testeur avec des erreurs, vous savez qu'il échouera.

Si le bogue est encore présent dans votre esprit et que vous avez le temps d'écrire le test unitaire maintenant, je l'écrirais maintenant et le signalerais comme un échec connu pour qu'il n'échoue pas la construction elle-même. Votre système de suivi des bogues doit être mis à jour pour indiquer qu’il existe actuellement un test unitaire qui échoue pour ce bogue, de sorte que la personne chargée de le corriger finisse par ne pas tout réécrire. Cela suppose que le code du buggy n'a pas besoin de beaucoup de refactoring et que l'API change de manière significative - dans ce cas, il serait peut-être préférable de ne pas écrire le test unitaire tant que vous ne saurez pas mieux comment le test doit être écrit. .

La réponse est AUCUN IMHO. Vous ne devez pas ajouter de test unitaire pour le bogue tant que vous n'avez pas commencé à travailler sur le correctif du bogue. Vous écrirez le (s) test (s) prouvant le bogue et en indiquant que ce test échoue conformément au rapport de bogue ( s) vous corrigerez le code pour faire passer le (s) test (s). Le bogue sera résolu et il sera couvert par la suite.

Dans mon monde, nous aurions un cas de test manuel où les QE échoueraient jusqu'à ce que le bogue soit corrigé. Et nous, les développeurs, en serions conscients via le TC défaillant manuel et via le traqueur de bogues.

La raison pour laquelle vous n’ajoutez pas d’UT défectueux est simple. Les UT servent à la rétroaction directe et à la validation de ce que je travaille actuellement en tant que développeur. Et les UT sont utilisés dans le système CI pour s’assurer que je n’ai pas cassé quelque chose par inadvertance dans un autre domaine de code pour ce module. Avoir des UTs qui échouent intentionnellement pour un bug connu IMHO serait contre-productif et tout simplement faux.

Je suppose que la réponse est vraiment, cela dépend. Soyez pragmatique à ce sujet. Qu'est-ce que l'écriture vous gagne maintenant? C'est peut-être frais dans votre esprit?

Lors de la correction du bogue, il est parfaitement logique de prouver son existence en écrivant un test unitaire exposant le bogue. Vous corrigez ensuite le bogue et le test unitaire doit réussir.

Avez-vous le temps d'écrire le test unitaire défaillant tout à l'heure? Y a-t-il plus de fonctionnalités urgentes ou de bugs qui doivent être écrits / corrigés?

En supposant que vous ayez un logiciel de suivi de bogues compétent avec le bogue enregistré, il n’est vraiment pas nécessaire d’écrire le test unitaire défaillant pour le moment .

On pourrait soutenir que vous pourriez créer une certaine confusion si vous introduisez un test d'unité défaillant avant une version en cours sans correction de bogue.

Je suis généralement mal à l'aise de connaître les échecs dans les suites de tests, car il est trop facile pour la liste de s'allonger avec le temps ou pour que des échecs sans lien dans les mêmes tests soient considérés comme "prévus". La même chose vaut pour les échecs intermittents - il pourrait y avoir quelque chose de mal caché dans le code. Je voterais pour l'écriture du test du code tel qu'il est actuellement, et tel qu'il devrait être une fois qu'il est corrigé mais commenté ou désactivé d'une manière ou d'une autre.