Tests:
Premier article d'une série sur les tests en Qt / C++.
Tiens, justement, je mets ça en place un peu plus drastiquement en ce moment.
Ce Joël a toujours le chic de faire rire quoi qu'il écrive :
If you don't specify what you expected to see, I may not understand why this is a bug. The splash screen has blood on it. So what? I cut my fingers when I was coding it. What did you expect? Ah, you say that the spec required no blood! Now I understand why you consider this a bug.
La suite : http://blog.soat.fr/2014/02/du-bon-usage-de-junit-22/
Je ne sais plus qui avait Shaarlié ça. Les infos semblent intéressantes.
Composer, c'est le pied. Maintenant, il va falloir apprendre à utiliser quelques outils PHP :-)
Les tests unitaires en Java, c'est le pied grâce à JUnit ! C'est vraiment le pied ! Dans un projet, j'ai même eu l'occasion de m'en servir pour des tests d'intégrations !
Cela devient plus compliqué dès qu'il faut tester des méthodes asynchrones utilisant des callback (ou listener, as your prefer). Je n'ai rien de complètement figé dans ma tête actuellement, mais voilà ce que je note :
La solution générique consiste à attendre l'appel du thread à l'aide de synchronized, wait et notify. Dans la réalité, il semble qu'il vaut mieux utiliser CountDownLatch (http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/CountDownLatch.html) afin d'éviter que le callback n'arrive avant que l'on est eu le temps d'attendre... ce serait dommage ;-)
Actuellement, pour moi, la meilleure solution consiste donc à utiliser un code du type :
public class AsynchronousTest
{
/**
@Test
public void testAsynchronousCall() throws Exception
{
Object parameters = null;
myAsynchronousCall(parameters, new MyCallback()
{
@Override
public void onSuccess(Object data)
{
receiveddata = data;
lock.countDown();
}
});
boolean releaseBeforeTimeout = lock.await(2000, TimeUnit.MILLISECONDS);
// Check timeout
if (!releaseBeforeTimeout) {
// Do stuff
fail("Timeout");
}
assertNotNull(receiveddata);
// Other tests
}
}