Go back to the main page

Quickly test drive the creation of a Grunt plugin. Part 2.

 

 


Code from screencast and tutorial is available on Github. The screencast has more detail and explanation than this tutorial.

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 custom_options.

  1. Plugin users can define the development Chrome extension directory using task options so let's add a test for custom_options.
    2. Test that the reload.html can be created in the tmp/dev directory.
    Run the tests to get some red.
  2. Edit the Gruntfile adding tmp/dev to the task options.
    3. This should work with no additional code.
  3. Run the tests again to get green.
    4. The reload.html file is being generated in the proper directory based on the extensionDir option.
    We are done testing the first plugin goal, which was to create a timestamped reload.html in a designated directory. The next aim is to create a reload.js file also in the Chrome extension development directory that will poll reload.html for a timestamp change and then issue a chrome.runtime.reload() on reload.html, which reloads the entire Chrome extension.
  4. The reload.js must also be created in the designated extension directory so let's start with another file existence check.
    5. Run it to go back to red.
    The reload.js files needs to know the location of reload.html, which is dynamic, so let's take advantage of grunt.template to solve this.
  5. Create a new file called tasks/reload.js.tpl with the following contents.
    6. Raw code is here.
  6. Before we get too far off track, let's get back to getting our tests green. In tasks/crx_auto_load.js add the following:
    7. The gray highlighted code should get the tests passing again. However, there is an warning stating that 2 assertions were expected but only 1 ran.
  7. Go back to test/crx_auto_load_test.js and change test.expect(1) to test.expect(2).
    8. While you're at it add a test for reload.js in the custom_options run. Back to green.
    Just testing for the file existence of reload.html is 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.html should be present in the processed version of reload.js.
  8. Create a new test named process_js_template.
    9. Run the test to go back to red.
  9. Back in tasks/crx_auto_load.js let's wire up the grunt.template and pump in the correct location of reload.html into reload.js.tpl.
    10. Again we are back to green.
  10. The /tmp directory is only cleaned out on the beginning of the test run so we can manually check that the template was processed by opening up tmp/reload.js
    11. Looking good, just as the test asserted.

Conclusion

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.

  • Pushed on 03/21/2014 by Christian