London JS: Visual Regression Testing, Continuous Deployment & SidekickJS

Tim Ruffles at London JS

London JS August covered a variety of things. Tim Ruffles came along to talk about SidekickJS, James Cryer spoke about his work with visual regression testing and Adam Rogers enlightened us with his thoughts on continuous deployment.


SidekickJS - Tim Ruffles

Over the last 6 months, Tim has been working on SideKick JS, his code quality tracking tool. He built this because he felt it was important to take stock of the code that was being produced in dev teams.

Tracking the quality of your code can benefit you in several ways, where one of the most important things is the gradual increase in the quality of your code. You know your code is now being monitored, so you're likely to pay more attention to your writing. SideKickJS gives stats on quality: being at the top of the proverbial leader board can make you feel pretty good and feel confident in your code base.

One of the most interesting parts of Sidekick JS to me was its fuzzy duplication detection; it flags up areas of your codebase that are structurally identical, indicating that it there may be duplicates and thus uneccesary code. I'm just starting out in JavaScript and there have already been several occasions where I've written duplicate code, so I can see this being quite useful for me.

SidekickJS is still relatively new and thus there are a number of things that need to be improved with this tool; it doesn't handle coffeescript or library specific code, nor does it work with object level metrics yet, but only deals with things at the function level. But it looks like Sidekick is going in the right direction and I'd definitely like to try it out!

Check out Tim's slides: http://timruffles.github.io/sidekick-js-talk/


Visual Regression Testing - James Cryer

Next was James Cryer and his talk on using PhantomCSS for visual regression testing. Until then, I had no idea what visual regression testing was. Now, I know that it is where we can monitor changes within a visual design.

PhantomCSS is a screenshot comparison library for CasperJS. In our day to day we're already doing manual visual regression testing, but it can be very time intensive and subject to human error. PhantomCSS allows us to automate this process and do it faster by simply taking screenshots of the design, comparing it to previous screenshots and reporting whether or not they are different.

It appears that visual regression testing with PhantomCSS doesn't work too well with anti-aliasing or animations, but it is quicker than human visual regression testing and gives much better reporting. Definitely worth looking into.

James's Slides: https://speakerdeck.com/jamescryer/visual-regression-testing-with-phantomcss


Continuous Deployment - Adam Rogers

Finally we had Adam Rogers talk about Continuous Deployment (CD). Adam firmly believes that it should be a trivial process to get your code into production and should only include a small amount of steps and people to get it done. Using CD, even if something goes awry, you can quickly deploy the necessary bug fixes smoothly and efficiently.

To ensure that your code is ready to be deployed, you can run tests on it. Did your code pass the test? Yes? Then there's a good chance it works so Adam says "don't worry and deploy that code!". You can even tie deployment into the testing process; if it passes, deploy the code.

To see whether or not your deployment was a success, get metrics;

"If it moves, put a metric on it".

Using Foldable.Me (a project he works on at Mint Digital) as an example of continuous deployment, he told us that recently when new code was deployed they noticed a drop in transactions. These metrics told them something was wrong and they could quickly go in and fix it.

What can be an important part of Continuous Deployment is the use of Feature Flags. You can still deploy stuff that isn't quite ready by turning features on and off for the general populus. You can also use feature flags to gently roll out new features to segments of users and see how well they are received, before going ahead and turning the features on for everyone.

Lastly; you shouldn't go ahead with the deploy until you've had someone else check your code. Once you have deployed, don't run to the pub; stick around and see if everything is okay first.

Ultimately, in Adams opinion, if you can't deploy quickly and easily your code is broken.

Adam's Slides: https://speakerdeck.com/rodreegez/daft-deploy-all-the-f-star-ing-time


I was introduced to a lot of things at this edition of London JS and even played with PhantomCSS a little afterwards. A great evening and lots of knowledge gained as always. Thanks to the fantastic speakers and everyone who came along.

- Charlotte