Alex Seville

Public.js is a little library I developed to display the public interfaces exposed by JavaScript source code.  

Basically, it determines what will be exported to the global scope (or returned via exports in node) and formats that object into a parse tree.

The applications (that I've thought of so far) are developing unit test scaffolding, or documentation for existing code, and analyzing code for accessor errors or unintentional exports of "private" functions.

DEPLOY by phil dokas on Flickr.

I've played with the Selenium FF plugin in the past, but found it to be a little awkward.  I decided to try creating an alternative, as a regression testing JavaScript library (but powered by a Chrome extension).

The result is Feta.  Feta will allow you (via the Chrome devtools extension) to record a series of behaviours in your webapp (one page apps only, for the moment).  When you stop recording, Feta produces a reusable test that can be run independently of the Chrome extension (or Feta itself).

The test scripts can also be run by PhantomJS, in order to add regression testing to your continuous integration pipeline.

So far I've been able to use it to regression test maintenance deployments at work, and the results are promising.

I'd appreciate any feedback or feature suggestions.

Typically when (browser based) distributables are include in a Github project they're added to the gh-pages branch.  This is done to avoid having duplicate changes in the commit logs for the source and distributable.  For example, changing a variable name in source, rebuilding, and then committing, would result in a commit containing a diff to the source AND each built distributable file.

However, there are use cases for having the distributable on your master branch, and I've developed a solution (of sorts) to make it work in a fairly clean manner.

For Blanket.js, I like to provide 4 distributable files, a QUnit and Jasmine build, and a minified version of each.  Adding these 4 files to a gh-pages branch is too much overhead.  I rebuild the project after each change to run my tests anyway, so I'd rather just have the new distributables live in master and be available after each commit to master.

Enter, .gitattributes.  Creating a .gitattributes file allows you to change the git attributes of given files.  According to the documentation you can tell git to handle your file as binary, so diffs won't be created:

`dist/*.js -diff`

In practice, this didn't work for me on GitHub (maybe it ignores the git attribute on files that have already been tracked?).  I have to change the merge attribute to union (which may not always give the intended result), but it works for me (I also run the distributables through tests on the CI):

`dist/*.js merge=union`

We had a great Lunch & Learn at Nurun yesterday.  We basically watched the following videos and chatted about them.  Paul Irish's talk has some great workflow tips (which led me to this awesome dotfile from Mathias Bynens).

1. JavaScript at 17 - Brendan Eich.

Blanket.js is the code coverage library I work on, which aims to be a drop-in solution to add code coverage stats to existing test runners.  I thought I'd try adding it to the Adobe Brackets test suite, both to see their coverage details, and to check if Blanket.js is up to the challenge.

Installation & Configuration

To start, I installed Brackets.  The details for using Brackets to edit Brackets are in the article How to Hack on Brackets.

Within the /test directory, we can see that the entry point for the unit tests is the file SpecRunner.html.  This is where we need to add the reference to Blanket.js to add the code coverage functionality.

Does it Work?

My first attempt was less than successful.  I added a reference to Blanket.js right below the reference to require.js in the SpecRunner.  My mistake was using the normal Jasmine build of Blanket.js, like so:

<script src="thirdparty/blanket/blanket_jasmine.js" data-cover-only="src/" data-cover-never="['thirdparty','test']"></script>

The data-cover-only and data-cover-never attributes are set correctly (to instrument the src files, but ignore the thirdparty and test files), but the Blanket.js Jasmine adapter was in conflict with the code with SpecRunner.js.  

Blanket Adapter

Luckily, it's very easy to create a new adapter for Blanket.js.  All I needed to do was remove the code in the Jasmine adapter that binded to page load.  I've created a gist to show the custom adapter I created.

Putting it All Together

Once I updated the script reference,

<script src="thirdparty/blanket/blanket_jasmine.js" data-cover-adapter="thirdparty/blanket/blanket-jasmine-brackets-adapter.js" data-cover-only="src/" data-cover-never="['thirdparty','test']"></script>

everything started working normally and the coverage results appeared below the unit test list:

Success!

There are some improvements to be made (a dialog showing instrumentation progress, for example), but it's encouraging to see code coverage results added with very little configuration.

If you're interested in contributing to Brackets or Blanket.js please visit the source repos for details:

Brackets on GitHub