Jag skulle kanske tryckt lite mer på att det i min mening inte lämpar sig för end-to-end-tester, typ ATDD eller BDD – där är fortfarande något som har Selenium i botten kung (om man gör det rätt).
The idea is OK I guess – run tests and production code in the same environment it will run in when deployed. There are a couple of cons to JsTestDriver (used through Eclipse) though:
- if you’re configuration file doesn’t include the test file you’re trying to execute, there’s no clue to what you’ve done wrong – the panel in Eclipse will just show the green bar and 0/0 tests run.
- if you have syntax (or construct like) errors in your unit under test, you’ll get the same behavior as above
- sometimes you’re served a cached version of (some of) the JS source files – hence there’s a button to “refresh browsers” and it’s sad that it has to be there and that you actually have to use it
- sometimes the engine gets into some strange state where it dryRuns the tests instead of actually executing them
Apart from that, its behavior is quite predictable. Minor issues:
- running a test complete locks Eclipse’s UI thread
- a Rerun quick command option would be great (Ctrl+3)
Another minor issue is that the “index” of JsHamcrest matchers is really hard to get an overview of. Whenever I wanted to use a certain type of matcher, it was really hard to quickly tell from the documentation if it was there or not. Go see for yourself and look for a matcher that mathes any object for instance.
# get a list of matchers:
curl "http://jshamcrest.destaquenet.com/modules/matchers.html" | grep "dt id" |cut -d '"' -f 2 |cut -d '.' -f 3
JsMockito works really nice. The only thing that could’ve been better is the integration with JsTestDriver: when a verify step fails, you’ll get a good error message but you don’t get the typical feedback as from which line the verify/assert that failed was on. Not a big deal since you see which test that failed.