Brian Lewis ModulesUnraveled

Contract Killer

The popular open-source contract for web designers and developers by Stuff & Nonsense

Originally published: 23/12/2008
Revised date: 15/12/2013
Original post

Keybase proof

I hereby claim:

I am ModulesUnraveled on github.
I am modulesunraveled (https://keybase.io/modulesunraveled) on keybase.
I have a public key whose fingerprint is F642 07CF 46D4 275F C947 EC06 73E5 E5C0 3212 5BD7

To claim this, I am signing this object:

Before anything else:

1Password: The best password manager (Need this early so that I can enter passwords for the rest of the stuff below)

App Store:

Mindnode: Mind Mapping
Keynote: Presentations
Numbers: Spreadsheets
Pages: Documents

Install Java command line tools

Install the latest Java JDK (not JRE)

Require all the things

npm install --save-dev webdriverio chai node-notifier wdio-mocha-framework wdio-browserstack-service wdio-visual-regression-service

Add the test scripts to package.json

{
  "scripts": {

Someone recently asked the following in Slack. I didn't want it to get lost in Slack's history, so I thought I'd post it here:

Question: I’m setting a css background image inside my Pattern Lab footer template which displays correctly in Pattern Lab; however, Drupal isn’t locating the image. How is sharing images between PL and Drupal supposed to work?

My Answer: I’ve been using Pattern Lab’s built-in data.json files to handle this lately. e.g. you could do something like:

footer-component.twig:

Intro

In this post, I'm going to run through how I setup visual regression testing on sites. Visual regression testing is essentially the act of taking a screenshot of a web page (whether the whole thing, or just a specific element) and comparing that against an existing screenshot of the same thing to see if there are any differences.

There's nothing worse than adding a new component, tweaking styles, or pushing a config update, only to have the client tell you two months later that some random other part of the site is now broken, and you discover it's because of the change that you pushed... now it's been two months, and reverting that change has significant implications.

That's the worst. Literally the worst.

All kinds of testing can help improve the stability and integrity of a site. There's Functional, Unit, Integration, Stress, Performance, Usability, and Regression, just to name a few. What's most important to you will change depending on the project requirements, but in my experience, Functiona

	#0. Update Drush to 7.x
	/* Taken from https://github.com/drush-ops/drush */
	a. Install Composer Globally

	curl -sS https://getcomposer.org/installer \| php
	sudo mv composer.phar /usr/local/bin/composer

	b. Make sure Composer's global bin directory is on the system PATH

	sed -i '1i export PATH="$HOME/.composer/vendor/bin:$PATH"' $HOME/.bashrc

	<?php


	/**
	* These aliases (while working) are NO LONGER MAINTAINED.
	*
	* Development has moved to a full github repo here:
	* https://github.com/ModulesUnraveled/Drush-Shell-Aliases
	*
	* I'm doing this to make it more easy to include them in your Drupal 8 projects.

	{#
	# This is the PL template for the "parent" pattern
	#}

	{% set flexible_grid_base_class = flexible_grid_base_class\|default('flexible-grid') %}
	{% set item_count = flexible_grid_item_count\|default(rows\|length) %}

	{# Dynamically define grid columns #}
	{% if item_count is divisible by(3) %}
	{% set flexible_grid_modifiers = ["columns-3"] %}