2013-04-26 6 views
2

Nous développons une application avec Scala et Websockets. Pour ce dernier nous utilisons Java-Websocket. L'application elle-même fonctionne très bien et nous sommes en train d'écrire des tests unitaires.Java Websocket à thread unique pour test

Nous utilisons une classe WebSocket comme suit

class WebSocket(uri : URI) extends WebSocketClient(uri) { 
    connectBlocking() 
    var response = "" 

    def onOpen(handshakedata : ServerHandshake) { 
    println("onOpen") 
    } 
    def onMessage(message : String) { 
    println("Received: " + message) 
    response = message 
    } 
    def onClose(code : Int, reason : String, remote : Boolean) { 
    println("onClose") 
    } 
    def onError(ex : Exception) { 
    println("onError") 
    } 
} 

Un test pourrait ressembler à ceci (code pseudo)

websocketTest { 
    ws = new WebSocket("ws://example.org") 
    ws.send("foo") 
    res = ws.getResponse() 
    .... 
} 

Envoi et réception de travaux de données. Cependant, le problème est que la connexion au WebSocket crée un nouveau thread et seul le nouveau thread aura accès à response en utilisant le gestionnaire onMessage. Quel est le meilleur moyen de rendre l'implémentation websocket mono-thread ou de connecter les deux threads afin que nous puissions accéder à la réponse dans le cas de test? Ou y a-t-il une autre, encore meilleure façon de le faire? En fin de compte, nous devrions être en mesure de tester en quelque sorte la réponse de la websocket.

Répondre

0

Il y a plusieurs façons de faire cela. Le problème sera que vous pourriez obtenir une erreur ou une réponse positive du serveur. En conséquence, le meilleur moyen est probablement d'utiliser une sorte de timeout. Dans le passé, je l'ai utilisé comme un modèle (note, ce code est non testé):

... 
use response in the onMessage like you did 
... 

long start = System.currentTimeMillis(); 
long timeout = 5000;//5 seconds 

while((system.currentTimeMillis()-start)<timeout && response==null) 
{ 
    Thread.sleep(100); 
} 

if(response == null) .. timed out 
else .. do something with the response 

Si vous voulez être particulièrement sûr, vous pouvez utiliser un AtomicReference pour la réponse.

Bien sûr, le timeout et le sleep peuvent être minimisés en fonction de votre scénario de test. De plus, vous pouvez envelopper ceci dans une méthode utilitaire.