primitives tests unitaires

Question

Est-il vaut la peine d'écrire des tests unitaires pour un tel code simple:

public class TableController { 
    private TableView view; 

    public TableController(TableView view) { 
    this.view = view; 
    } 

    public void onShowTable() { 
    view.showTable(); 
    } 
} 

J'ai beaucoup de ce code très simple dans mes projets qui relie les contrôleurs, vues, services, services à distance Les tests unitaires répètent tout et sont généralement plus grands que le code lui-même:

public class TableControllerTest { 
    @Test 
    public void showTable() { 
    TableView view = createMock(TableView.class); 
    view.showTable(); 

    replayAll(); 

    TableController controller = new TableController(view); 
    controller.onShowTable(); 

    verifyAll(); 
    } 
} 

De tels tests sont-ils vraiment nécessaires?

Merci!

Answer 1

Non. Vous n'avez pas besoin de tout tester à l'unité. D'un autre côté, vous pouvez essayer d'inverser le processus et d'écrire les tests en premier, puis le code. Dans de nombreux cas, vous constaterez que si vous écrivez le test en premier, vous finissez par écrire un code différent de ce que vous pensiez en fonction de ce qui devrait être le résultat lorsque vous écrivez le test plutôt que du code. Devrais-je écrire. En écrivant des tests de cette manière, vous constaterez que les tests ont beaucoup plus de valeur que de simplement exercer le code avec eux. Une fois que vous avez compris, vous aurez également une idée de quand vous avez besoin du test et quand vous n'avez pas - les accesseurs de propriété automatiques, par exemple, n'ont pas besoin d'être testés unitairement IMO.

Si vous faites déjà les tests en premier, alors je ne suis pas sûr de comprendre la question car vos tests ne peuvent pas répéter quelque chose qui n'a pas encore été écrit. Vous avez utilisé vos tests pour définir ce que les méthodes devraient faire. C'est une activité très utile et également protectrice dans le cas où d'autres tests provoquent un changement de rupture. Il vaut mieux le trouver dans un test unitaire que dans une application en direct.

Answer 2

Différentes personnes auront des opinions différentes. Vous devez absolument tester tout ce qui pourrait mal tourner. Ce que cela signifie pour vous dépend de vous. Des tests excessifs peuvent ralentir la productivité tout comme trop peu de tests peuvent manquer des problèmes. Vous devez déterminer ce qui fonctionne pour vous.

Answer 3

Elles sont nécessaires lorsque vous modifiez l'implémentation de votre méthode et devez vous assurer que cela fonctionne toujours. Et quand cela arrive 2 ans plus tard, il est trop tard pour essayer de se rappeler comment la méthode a fonctionné pour écrire un test unitaire - vous devriez le faire MAINTENANT. Ils sont moins nécessaires lorsque vous les comparez à des tests sur des méthodes/logique plus compliquées, mais ils sont néanmoins nécessaires.

Answer 4

Les tests sont toujours une bonne chose surtout si vous vous attendez à ce que votre code croisse avec le temps. Il est utile de pouvoir vérifier si les anciennes fonctionnalités fonctionnent correctement après la refactorisation ou d'apporter des modifications majeures à votre base de code. Dans votre cas spécifique, je pense que la fonctionnalité de ces bits de code est trop petite pour bénéficier des tests et des tests que l'exercice showTable etc. serait plus utile.

Answer 5

Je ne testerais pas les méthodes de délégation simples.

Il est bien dit (bien que je ne me souviens pas qui il venait): « Jamais substance de test qui est trop simple pour briser ... »

Answer 6

Code

dans mes projets qui relie les contrôleurs, vues , services, services à distance, etc.

Pour ce genre de chose, les tests unitaires ne sont probablement pas utiles - mais les tests d'intégration sont, c.-à-d.tests qui vérifient que la fonctionnalité de l'application dans son ensemble (probablement sur la base d'un cas d'utilisation) avec un minimum de moquerie. Ceux-ci prennent plus de temps et ne peuvent pas parcourir tous les cas de bords, mais ils sont très utiles pour révéler des problèmes dans la façon dont les composants interagissent - et dans ce type de code de colle.

Answer 7

Les tests pour des modules de ce type ne sont pas vraiment nécessaires. Cependant, les tests pour de tels modules ne sont pas difficiles à écrire. Donc, il n'y a vraiment aucun mal à écrire les tests. Vous devez également vous rappeler que les modules simples du type que vous avez montré tendent grandissent au fil du temps. Si vous n'avez pas de test pour le module, lorsqu'un nouveau bit de logique est ajouté au module, vous pouvez décider que le delta entre l'ancien module et la nouvelle logique est trop simple à tester. Peu à peu le module grandit sans être testé. Donc à la fin, j'écrirai les tests, même pour des modules simples, car ils sont simples à écrire, et ils servent de substituts lorsque les modules deviennent plus compliqués.