|jsTestDriver using watchr|
All the code from this blog entry can be found on github. Under a busterjs and jstd branch. https://github.com/finnjohnsen/jstesting
I've noticed, and none I've found are attractive at all.
- I've seen set-ups which involves refreshing or triggering the tests from your browser. For example at the Jasmine -site, this is what they document. This is a lot better than the previous bullet point. But we can do better.
- The Selenium approach: Automate and play back clicks and input-text into your browser. These kind of behavior tests are tightly coupled to html, slow and messy. But they have value as they ensure your site actually works! But it's not what I want for unit testing.
Buster.JS or JsTestDriver: My Conclusion
- jsTestDriver requires more patching, hacking and scripting, but works well once you've got it running. You'll probably polish and tune your scripts for quite some time after you've got it running, but you have something working pretty easily. JSTD has wide adaptation and you'll almost certainly find a solution to your problems just by searching around a little. You can have a look at this wrapper, which is suppose to ease the scripting from JsTestDriver. Anyway, check out my sample set up.
- Buster.JS is a bigger creature. It seems to aim to provide you with some of the pieces missing in JsTestDriver. It provides contrinous/auto testing and an built-in assertion library. These two critical components are what made the installation and set-up of jsTestDriver take a while longer than buster. So check out my sample set up.
Buster.JS states on it's website it is under heavy development. It even and uses the word 'unstable' to describe its current state. Leaving JSTD the choice if you can't live with that. Personally I like getting as much set up for me as possible, and I found nothing mentionable when setting up Buster.JS. So I will use Buster.JS on my next green field. I can however be considered biased, one of the authors of Buster.JS work in the same company as I.
This is nice and all, but the real world is bigger than this
... and nobody said it was going to be easy.
I found nothing in these projects which mentions, or in any significant way help you on how you should incorporate these para dimes into your real world web framework. So if you're using Rails, .NET or Grails, you're on your own hacking and slashing this stuff into your source code. You'll have a system within your system.
I also find it immensely difficult to test UI code. That is, code working with the DOM, utilizing templating like Handlebars.js or Mustache.js. And whenever I see jQuery I know I'm in trouble. It is unfair to blame these technologies for not helping you with this, so I won't. I'm just saying this is unsolved and up to you to mess about with on your own.
Personaly, my pure GUI code is not covered by any tests in my projects. I'm still searching for a sensible way to organize so I can test as much as I should. I'm looking for good coding standards on how to organize my code and .js -files. At the moment, I'm inventing stuff as best I can as I go along. I've typically got *-view.js which are untested, and contains the messy CSS selectors and stuff. And I have typical *-model.js which are the ones I test.
Continous integration is also something I've only tried for 15 minutes and given up. Maybe I'll blog about this when I solve it. You won't get this for free either.
I plan making a follow up blog entry covering an example (how I do it) on how to get this into a Grails project.
Get your hands dirty already!
Head over to https://github.com/finnjohnsen/jstesting and look at the simple skeleton set-up I made for the sake of this post. The project has a jstd and buster.js branch for you to look at.
Pros, Cons and anoyancesThese are my raw notes when getting the simple skeleton set up.
- Created by Google and seems widely adopted and easy to search for questions, answers and sample setups.
- Has a nice set-up video on the official site. http://www.youtube.com/watch?v=V4wYrR6t5gE
- This video is gets eclipse specific when it comes to the automated testing.
- The web site is ugly and messy. I don't find it intuitive where to find what I need. Also the wiki linking to source often don't work.
- You'll spend an hour setting this up even though the video made it seem easy. You'll have to create scripts which you'll tweak quite a bit over time before you're happy.
- The project provides no proper continuous testing. I created a watchr script for this.
- It was a little difficult finding the QUnit adapter or whatever assertion framework is supposed to be default. I blame the poor website for this.
bumps in the road:
- Difficult to put the config file other places than in the root of the project. I gave up on this and ended up polluting my root with the config file.
- The jsTestDriver.conf is case sensitive. Stole a few minutes to figure out I had incorrectly put it all in lower case.
- Have to repeat the port number in the port file and the configuration file. I don't like having to remember stuff.
- I had to create a dummy test.js to be able to start the server the first time.
- The default assert library on the site directed me to a dead link, so I chose QUnit.
- Can't figure out how to get colors in console. I miss the Test(s) failed or Test Successful which is convention everywhere you do TDD.
- The projects provides an eclipse plugin. I couldn't get it working however. I gave up quickly though.
- I got automatic relaunch of tests when files were touched. No need for watchr.
- Got coloring in the console. Red and Green for failed and successful tests respectively.
- The config file (buster.js) is easily put in test/ instead of root. Repeat after me: "I hate polluting root directory"
- The web site is decent.
- I don't like having to mess with Node.js in my OS. Wish it was stand alone or just in my home folder
Bumps in the road:
- I couldnt get the expression test/*Test.js working. I prefer calling tests e.x personTest.js, not person-test.js. No biggie.
- I intially had test/*.js in buster.js, but buster.js was in test/ as well, and I was trying to run buster.js as a test, which it isn't. Got weird errors which wasn't pointing me in the right direction.
- I don't like having to run run the npm command as sudo. Unknown stuff leaking into my OS.
Thanks, feel free to comment :)