Blog

20 Jul 2015
|

In recent months I've been demoing visual monitoring to many developers. The reaction was always positive, but I've realized that not enough people have taken the step from recognizing the need to actually implementing it on their own projects.

If you have been following my recent blog posts or tweets you've probably noticed we are trying to bring visual monitoring along with Shoov to the masses. To do so we're trying to reduce the complexity and codify our "lessons learned".

Drupal.org visually monitored by Shoov

Yeoman generators is one way to achieve this. With the new yo shoov - a single command makes sure all the files needed for visual monitoring are immediately scaffolded in your repository. In fact, it also sets up Behat tests along with a .shoov.yml that will allow Shoov to run your visual monitoring tests periodically.

Since visual monitoring might be new for a lot of people, the generator not only scaffolds the files but also attempts to check if your system is properly installed, and tells you how to fix it if not.

Shoov generator in action.
25 Jun 2015
|

Following our unfortunate bug in Shoov which caused login to stop working, we decided to write a Behat test that will continuously check the live site and make sure login with GitHub is working properly.

Writing the Behat test was pretty easy, however it had a major problem - it didn't work.

@javascript
Scenario: Login to shoov
  Given I am an anonymous user
   When I visit the homepage
    And I login with my GitHub account
   Then I should wait for the text "My Account" to "appear"

When Behat sees the @javascript tag in the begining of the scenario, it launches it (with the help of Mink extension) in PhantomJS, Firefox or Chrome.
PhantomJS is usually the easiest to configure and hook into the CI workflow later on.

But the test we wrote just failed on all versions of PhantomJS we tried. Which made us switch to Firefox instead. Travis CI is kind enough to have a headless Firefox installed in their machine which we could use. Unfortunately, Firefox didn't like our test either, but for another reason - it couldn't parse the xpath we use to find our text elements.

So after spending some time trying to figure out a workaround, I suddenly stared at the browser I was using to find the answer - Chrome!

Behat test running on headless Chrome, seen via VNC
01 Jun 2015
|

Irony presents itself in many forms. Not being able to login to a site that is responsible for testing that the login is working properly on other live sites, is one of them.

As much as I'd like to say I was able to enjoy the irony, the six hours I spent tracking the bug were slightly frustrating.

One of the things Shoov is built for is assisting us with a quick configuration of live site monitoring using your preferred functional testing tool (e.g. Behat or CasperJS).
As awesome as services like Pingdom are, they still provide very little insight to what's actually going on in the site. In fact, according to Pingdom, Shoov was up and running, even though no user could have logged in.

Shoov login now working. When it wasn't, the fish were sad

Post Mortem

At this point of time I think very few people care about the "post mortem" of this incident since Shoov is still a work in progress, however some interesting lessons were learned, and some contributions were made.

23 May 2015
|

In this guest post, Luke Herrington shares his experience with integrating an existing Drupal backend with a Backbone.Marionette Todo app.

If you're reading this, you probably already know about all of the great work that Gizra has done in the Drupal/REST space. If you haven't, I highly recommend you check out their github repo. Also see the RESTful module.

One of the projects that Amitai has contributed is Todo Restful. It shows an Angular implementation of the canonical TodoMVC Javascript app connecting to a headless Drupal backend. It's a great demonstration of how easy exposing Drupal content with the RESTful module is. It also shows that when a RESTful API adheres to best practices, connecting it with clients that follow the same best practices is like a nice handshake.

I saw the Todo Restful project and it got me thinking, "If Amitai did this right (hint: he did), then I should be able to get this working with Backbone pretty easily". I was pleasantly surprised!

Todo app with a Drupal backend

Here's a simplified list of everything I had to do to get it working:

20 May 2015
|

As we dive deeper into visual regression testing in our development workflow we realize a sad truth: on average, we break our own CSS every week and a half.

Don't feel bad for us, as in fact I'd argue that it's pretty common across all web projects - they just don't know it. It seems we all need a system that will tell us when we break our CSS.

While we don't know of a single (good) system that does this, we were able to connect together a few (good) systems to get just that, with the help of: Travis-CI, webdriverCSS, Shoov.io, BrowserStack/Sauce Labs, and ngrok. Oh my!

Don't be alarmed by the long list. Each one of these does one thing very well, and combining them together was proven to be not too complicated, nor too costly.

You can jump right into the .travis file of the Gizra repo to see its configuration, or check the webdriverCSS test. Here's the high level overview of what we're doing:

Gizra.com is built on Jekyll but visual regression could be executed on every site, regardless of the underlying technology. Travis is there to help us build a local installation. Travis also allows adding encrypted keys, so even though the repo is public, we were able to add our Shoov.io and ngrok access tokens in a secure way.

We want to use services such as BrowserStack or Sauce-Labs to test our local installation on different browsers (e.g. latest chrome and IE11). For that we need to have an external URL accessible by the outside world, which is where ngrok comes in: ngrok http -log=stdout -subdomain=$TRAVIS_COMMIT 9000 from the .travis.yml file exposes our Jekyll site inside the Travis box to a unique temporary URL based on the Git commit (e.g. https://someCommitHash.ngrok.io).

WebdriverCSS tests are responsible for capturing the screenshots, and comparing them against the baseline images. If a regression is found, it will be automatically pushed to Shoov, and a link to the regression would be provided in the Travis log. This means that if a test was broken, we can immediately see where's the regression and figure out if it is indeed a bug - or, if not, replace the baseline image with the "regression" image.

Visual regression found and uploaded to shoov.io