So what are those 4 lines inside the `guard ‘jasmine-headless-webkit’ do` block? As you’ve probably guessed they’re just the set of directories that guard should watch. Now when you save PlayerSpec.js again you’ll see the terminal immediately run your tests and show your the notification that all is well (assuming your tests still pass!). Once you save your Guardfile, there’s no need to restart guard, it’ll notice the change to the Guardfile and automatically restart itself. You should end up with something like this: To get it working the easiest way is to edit the ‘spec_location’ variable (on line 7 – just remove the ‘_spec’), and do the same to the last line of the `guard ‘jasmine-headless-webkit’ do` block. Guard is expecting your spec files to have the format ‘my_spec.js’ – note the ‘_spec’ at the end.
A large amount of the file is comments and optional configs, which you can delete if you like. If you open up the Guardfile in your editor you’ll see it has about 30 lines of configuration.
Thankfully this is trivial to fix – we just need to edit the Guardfile. The reason for this is that the Guardfile generated by `guard init` isn’t quite compatible out of the box with the Jasmine folder structure. Now try editing that file and hitting save – nothing happens. You can find them inside the spec/javascripts directory and by default there’s just 1 – PlayerSpec.js. What about those 5 tests? They’re just examples that were generated by `jasmine init`. This is great for working on a laptop where you don’t have the screen real estate to keep a terminal window visible at all times. You’ll see that 5 tests were run in about 5ms, and you should have seen an OS notification flash up telling you the same thing. We see guard starting up, telling us it’s going to use TerminalNotifier to give us an OS notification every time the tests finish running, and that it’s going to use JasmineHeadlessWebkit to run the tests without a browser. What you should see at this point is something like this: Thankfully both jasmine and guard provide simple scripts to get started:Īnd we’re ready to go! Let’s test out our setup by running `guard`: Now we’ve got our dependencies in line it’s time to set up our environment. This might sound redundant – our tests are already going to be executed in the headless webkit environment, so why bother running them in the browser too? Well, the browser Jasmine runner tends to give a lot more information when something goes wrong – stack traces and most importantly a live debugger.įinally we add the terminal-notifier-guard gem, which just allows guard to give us a notification each time the tests finish executing.
Using guard livereload full#
Next up we grab guard-livereload, which enables Guard to act as a livereload server, automatically running your full suite in the browser each time your save a file. Next we’re going to add the ‘jasmine-headless-webkit’ gem and its guard twin, which use phantomjs to run your tests on the command line, without needing a browser window. First we grab the excellent Jasmine JavaScript BDD test framework via its gem – you can use the framework of your just but I find Jasmine both pleasant to deal with and it generally Just Works. This just installs a few gems that we’re going to use for our tests. Guard-livereload terminal-notifier-guard -no-rdoc -no-ri
Using guard livereload install#
Gem install jasmine jasmine-headless-webkit guard-jasmine-headless-webkit guard \ Let’s start by making sure we have all the gems we need: It has a great ecosystem around it which makes automating filesystem-based triggers both simple and powerful.
Using guard livereload code#
Guard is a simple ruby gem that scans your file system for changes and runs the code of your choice whenever a file you care about is saved. Because I’ve used a lot of ruby I’m most comfortable using its ecosystem to achieve this, and as it happens there’s a great way to do this already. This was a fantastic way to work, and I wanted to get there again with JavaScript. One of the things I really loved about Rails in the early days was that it introduced me to the concept of autotest – a script that would watch your file system for changes and then automatically execute your unit tests as soon as you change any file.īecause the unit test suite typically executes quickly, you’d tend to have your test results back within a second or two of hitting save, allowing you to remain in the editor the entire time and only break out the browser for deeper debugging – usually the command line output and OS notifications (growl at the time) would be enough to set you straight.
0 kommentar(er)
