VGTech is a blog where the developers and devops of Norways most visited website share code and tricks of the trade… Read more

Are you brilliant? We're hiring. Read more



JavaScript Code Style


Code is read much more often than it is written. Having a consistent and defined coding style helps developers read the code, and it also helps to make a code base feel like one unit, instead of individual pieces written by different authors with their own way of doing things.

Having a coding standards is beneficial, but making people follow it is usually a bit harder. Let me introduce two awesome tools to help you: JSHint and JSCS. (more…)

Writing, testing and publishing Javascript modules


So you want to write reusable, maintainable and modular Javascript, huh? Good.

Here’s a rather extensive “getting started”-guide by yours truly – which means it’s my own preferred way of doing things. It’s written with open-source in mind, but most points can be applied to “private” modules as well.


NPM, Travis, Node 0.8 and the “Caret Operator”


If you have a node.js project that you want to have tested using Travis-CI, you may run in to a problem if you want to support node <= 0.8. The reason for this is the new caret operator, which was introduced in node-semver.

This module is used by npm to figure out how to resolve versions for your dependencies, and while it’s a great idea, it fails to work on older node versions without upgrading npm first. It’s actually fairly trivial to fix this, however. (more…)

Setting up a mobile device lab


It is becoming more and more challenging to test apps and websites on different devices, with different screen sizes, running different operating systems and with multiple browsers installed. How can you guarantee that your website or app works on every device and on every browser?

Nothing beats testing on the same devices as your users, not emulated or simulated versions of those devices. Physical interactions like pinching, zooming and scrolling, hardware features like the camera, GPS locations, the accelerometer, testing real occurring events like battery consumption or site performance are all best tested using physical devices.

Generating code coverage of Behat tests


Yes, I know, it sounds silly, but bear with me.

The nature of acceptance tests is not really to tests units of code, but to assure that the behavior of your application meets a certain set of criteria (Behat Scenarios).

When your applications grow over time, code coverage can be a nice tool to help you pinpoint where you need to add more tests. In a perfect world tests are added while implementing new features so that your applications are always fully tested, but that isn’t always as easy as it sounds.

This post is a follow-up to Using PHP’s built-in web server in Behat tests that was published some months back, so if you haven’t read that one yet make sure to do so before continuing. If you are not familiar with Behat I suggest you have a look at the quick intro guide as well.


EditorConfig: Consistent coding style


If you’ve worked on more than one project in your coding career, you’ll probably have come across different coding styles. While some projects prefer an indentation of four spaces, others might prefer to only use two. Some may even use tabs. Then there’s line-endings, charsets and trailing whitespace.

When you are contributing to a project, it’s a good idea to try and follow the coding style already in place. This makes it more likely that your contributions will get accepted, and is in general a Nice Thing™ to do. So how can we simplify the task of setting up our editor to use a project coding style? Enter: EditorConfig.


Using PHP’s built-in web server in Behat tests


Behat is a tool for running acceptance tests for your application. If your application is a web application you will need a web server to execute your tests. This is not likely an issue when running your tests locally since you probably have a web server running on the development server that you can use, but when you execute your tests on Travis-CI for instance (you use Travis-CI right? RIGHT?!) it can be cumbersome getting a local Apache up and running for your test suite to use.

Some weeks back I wrote a post showing you how to use PHP’s built in web server in PHPUnit. This post will show you how to do the same for Behat when running your acceptance tests.


Using PHP’s built-in web server in your test suites


As of PHP-5.4.0 the CLI SAPI provides a built-in web server. The web server is designed for development purposes, and serves requests sequentially. This web server can come in really handy when the need for an httpd arises during (integration) tests.

In this post I’ll use PHPUnit as the testing framework, and I’ll show you how to start the web server during the bootstrap process, and how to shut it down when the test suite is finished.


Running multiple versions of PHPUnit


The latest version of PHPUnit (3.6.4 at the time of this writing) does not play well with the Zend Framework extensions (Zend_Test_PHPUnit). After asking Matthew Weier O’Phinney about this he answered that they had standardized on PHPUnit-3.4 for ZF1.

Having just upgraded to the latest version of PHPUnit on our servers we were no longer able to test our Zend Framework applications. One option was to downgrade PHPUnit, but since we were already using some of the new features this was not going to happen.

One solution to this problem is to run multiple versions of PHPUnit and use specific versions for specific test suites. Not optimal, but at least it gets the job done. (more…)