Tag: junit

10 raisons pour encourager les tests unitaires dans vos équipes

Les tests unitaires ne sont pas un coût mais un investissement. Voici donc 10 raisons pour lesquels un chef de projet ou de département doit considérer sérieusement les tests unitaires.
C’est le dernier article d’une série de 12 sur les tests unitaires expliqués aux managers.

A propos de budget

  • Les TU sont moins chers que les tests de régression ou d’intégration
  • Les TU sont moins chers que de corriger les bugs
  • Les TU rendent la maintenance moins chère et moins risquée

A propos de management

  • Les TU sont motivants pour vos équipes
  • Encourager les TU vous fait paraître plus moderne
  • En cas de départ d’un membre les autres peuvent prendre le relais sans craintes

A propos de méthode

Où vous situez-vous ?
Déterminez votre situation et vos moyens d’action grâce au tableau suivant (en anglais)

[table id=2 /]

Unit Tests Explained To Managers In 10 points. Test Culture Episode 12.

Here are 10 reasons why you, as a manager,  should care about unit tests. It’s a summary of this series of 12 articles on unit tests for managers. Continue reading “Unit Tests Explained To Managers In 10 points. Test Culture Episode 12.”

Good Unit Test CheckList

Writing unit test? but don’t know if you covered everything? Here is a simply good unit test checklist.

Here are a few items I try to respect every time I write unit tests. It’s a solid and good unit test checklist. At least good for most of my code 🙂

Edit: a more extended and detailed list I wrote for DZone.

  • My test class is testing one and only one class
  • My methods are testing one and only one method at a time
  • My variables and methods names are explicit
  • My test cases are easy to read by human
  • My tests are also testing expected exception with @Test(expected=MyException.class)
  • My tests don’t need access to database
  • My tests don’t need access to network resources
  • My tests respect the usual clean code standards (length of lines, cyclomatic complexity,…)
  • My tests control side effects, limit values (max, min) and null variables (even if it throws an exception)
  • My tests can be run any time on any place without needing configuration
  • My tests are concrete (ex. dates are hardwired, not computed every time, strings too…)
  • My tests use mock to simulate/stub complex class structure or methods

Maybe you’ve already done a great deal  by appointing a Test Supervisor that checks every aspect of the finished product. That’s terrific. Congratulations.

But there are still bugs ?  Your team is telling you that this little change you asked took the all system down ? How comes ?

For more details about unit tests, see my series:  Test Culture Episode 1. The 101 Unit Testing Guide For Busy Managers.

I’m pretty sure there are more point to this unit test checklist.  Any idea ?

Test Culture Episode 8. Moving Sh*t Around.

« If you don’t have unit tests, you are not refactoring, you are just moving shit around »

I’m so sorry. I could not find the source of this quote. But you get the meaning anyways. Or maybe not… Maybe you just think that unit tests are optional and refactoring is even more optional.

Continue reading “Test Culture Episode 8. Moving Sh*t Around.”

Test Culture Episode 7. “Tests Are Broken ? Let’s Ignore Them !”

No.  You can’t !

As a manager the only bossy instruction you should give is :

 “Don’t you ever shut down a crashing test ! Fix it now !”

Continue reading “Test Culture Episode 7. “Tests Are Broken ? Let’s Ignore Them !””

Test Culture Episode 6 : Unit Tests Are Better Than Excellent Specifications

Let me rephrase : GOOD unit tests are better than excellent specifications.
Unit tests actually ARE the specifications.