Alex Seville
JavaScript engineer, based in San Francisco, working for Flickr, and creator of Blanket.js.
DEPLOY by phil dokas on Flickr.
I’m really proud to have recently joined the Flickr team and to have been part of the new redesign project.
Head on over and see the changes, or rediscover the site anew!
http://www.flickr.com
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.
Check out the project page for more details and a walkthrough video.
izs:
Got this email this morning:
From: Andrew To: i@izs.me Subject: Have a minute to talk about npmjs.org? Hello, We have a client interested in npmjs.org. Would you consider selling the site? Please let me know a day, time and phone number you could speak about this possibility and we'll try to...
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`
You can see a Pull Request without and with the git attributes in place (I’m aware that I’m probably getting the right result for the wrong reasons, but the approach should work in theory if done correctly).
Really handy for i18n applications…
Show Paint Rectangles! Nice, this has been available in some Chromium builds for a while, but it’s great to see that it’s closer to being in Chrome stable.
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).
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
Blanket.js on GitHub
