Quickly test drive the creation of a Grunt plugin. Part 2.
Continuing from Part 1
In Part 1, I conjured up the Yeoman
generator-gruntplugin to rapidly launch the creation of a grunt plugin that would help inject auto reloading behavior to a Chrome extension project. Let's pick things up by testing the
- Plugin users can define the development Chrome extension directory using task options so let's add a test for
- Edit the
tmp/devto the task options.
- Run the tests again to get green.
reload.jsmust also be created in the designated extension directory so let's start with another file existence check.
- Create a new file called
tasks/reload.js.tplwith the following contents.
- Before we get too far off track, let's get back to getting our tests green. In
tasks/crx_auto_load.jsadd the following:
- Go back to
- Create a new test named
- Back in
tasks/crx_auto_load.jslet's wire up the
grunt.templateand pump in the correct location of
/tmpdirectory is only cleaned out on the beginning of the test run so we can manually check that the template was processed by opening up
reload.htmlin a designated directory. The next aim is to create a
reload.jsfile also in the Chrome extension development directory that will poll
reload.htmlfor a timestamp change and then issue a
reload.html, which reloads the entire Chrome extension.
reload.jsfiles needs to know the location of
reload.html, which is dynamic, so let's take advantage of
grunt.templateto solve this.
reload.htmlis one thing as we know the timestamp is going to work but for something more complex like processing a template let's test drive that. We know that if the template in Figure 6 is processed correctly that the text
reload.htmlshould be present in the processed version of
We dug a little deeper in Part 2 testing a more complex template rendering scenario. Part 3 of tutorial is just around the corner but you can watch the screencast now.