Webdriver (ChromeDriver) avec Play?

Question

J'utilise ChromeDriver avec Play! cadre. J'ai un UnitTest où ChromeDriver est instancié et envoie une requête get à mon URL Dyndns. Lorsque le test démarre, il ouvre le chrome, fait la demande mais il n'y a pas de réponse. Il attend indéfiniment. Et quand j'ai fermé le chrome, testrunner échoue avec l'exception;

Un org.openqa.selenium.WebDriverException a été pris, Chrome ne pas répondre à 'NavigateToURL'. Le temps écoulé était de 116077 ms. Demander détails: ({"command": "NavigateToURL", "navigation_count": 1, "tab_index": 0, "url": "http://myurl.dyndns.org:9000/test/", "windex ": 0}). (AVERTISSEMENT: le serveur n'a fourni aucune information stacktrace) Build info: version: '2.5.0', révision: '13516', heure: '2011-08-23 18:29:57' Informations système: os .name: 'Windows Vista', os.arch: 'x86', os.version: '6.0', java.version: '1.6.0_21' information du conducteur: driver.version: RemoteWebDriver

Lorsque Je n'utilise pas UnitTest (et TestRunner) et commence mon test directement avec une méthode principale (en initialisant aussi le Play par moi-même). Mais j'ai besoin des méthodes d'assertion de JUnit et il vaut mieux que tous les tests soient exécutés à partir du même module (j'ai beaucoup d'autres tests unitaires et fonctionnels). Des idées pour résoudre ce problème? Merci.

Answer 1

Qu'est-ce qui se passe est que les http://localhost:9000/@tests Déclenché une requête Web à http://localhost:9000/@tests/<your_test_class>.class pour exécuter votre classe de test prenant un fil, votre test tente de déclencher une demande de http://localhost:9000/your_path qui bloque jusqu'à ce que la demande de http://localhost:9000/@tests/<your_test_class>.class finitions. Ainsi, vous attendez indéfiniment puisque par défaut le nombre de threads est un. Donc, si vous augmentez play.pool> 1, votre suite de tests fonctionnera correctement.

Voir conf/application.conf

# Execution pool 
# ~~~~~ 
# Default to 1 thread in DEV mode or (nb processors + 1) threads in PROD mode. 
# Try to keep a low as possible. 1 thread will serialize all requests (very useful for  debugging purpose) 
# play.pool=3 

Note: Une chose que je trouve utile pour comprendre comment le travail de @tests tourne sur le réseau en chrome, alors je pourrais facilement retracer comment il fonctionne et il fait plus sens où le bloc était.