Ember Blueprints part 2: putting Ember Blueprints to the test

This is the second in a multi-part series looking at custom Ember Blueprints.  In part one we built an Ember Blueprint to generate read, edit and create form pages for an Ember Model, based around its attributes.  At the end, we’d got a working blueprint.  However, we didn’t test it, and it was only really useful within the project we authored it.

This second part is going to start and address those issues.

Now, I’ve got some good news and some bad news: the bad news is, if you’re not familiar with Ember, Ember Add-Ons, and Ember Blueprints then there is a lot of information in here.  In addition, we’re going to be heading into some choppy, un-documented waters.

But don’t worry, I’ve made this post as accessible as possible and dropped in a number of support links throughout.  Go as slow or fast as you like.  Read it twice.  Scan it to get a feel and then park it for reference later. It’s your content now, and I won’t be offended if you decide to leave. Much.

Follow Along At Home

The completed add-on for this blog post can be found on Github here:


At the end of each section where I’ve made a commit, I’ll include a link.

Creating Our Add-On

Ember Add-Ons are created just like Ember Applications, by using the Ember CLI.  In this case the command ember addon <add-on-name> will create a folder <add-on-name>  and add all of the required files to get started.  To create the add-on in the current directory then simply ember addon <add-on-name> --directory ..

An outline of the Add-On project structure can be found here:


However, the blueprint  folder isn’t automatically created for you, as it’s only required if your add-on is going to provide Blueprints.  This one definitely is, so we’re going to need that folder.

The content for our Blueprint was already created in the last blog post, and exists in the my-first-blueprint  branch.  Fortunately, Git never ceases to amaze me, and there is a command for copying a folder from one branch to another.  Well, of course there is…

It also requires a simple npm install --save string  which is used by the Blueprint’s index.js when processing the generate request.

Git Commit:


And with that, our Add-On should be ready to be imported into another Ember project.  It’s easily tested.

Oddly enough, despite throwing an error, this is good news.  This simply indicates we don’t have a model config for the person  model, which is very true.

The other warning that we received isn’t relevant to this project, but if you’re curious it’s related to this issue: https://github.com/ember-cli/ember-cli/issues/6219


So now we’ve proven the Blueprint is installable to other projects, we need to ensure it’s working correctly.  For that we need some tests.

Testing Blueprints is not a well documented process, so let’s break down what we’d like to do:

  • Create a test instance of an Ember application.
  • Generate our model-crud Blueprint from a known Ember Model config into the test instance of the Ember application.
  • Run functionality tests against the test application to check the output of the Blueprint works as we hope.
  • Tidy up, so we can repeat this test at will as we make updates to the Blueprint.

The Ember eco-system is chock-full of great add-ons, and in fact there is one to help with testing Blueprints – https://github.com/ember-cli/ember-cli-blueprint-test-helpers.


Once you have ember install ember-cli-blueprint-test-helpers  within your project, you can use the ember generate blueprint-test my-blueprint  command to generate the outline of a blueprint test.

The outline test exists in node-tests/my-blueprint-test.js , which roughly does the following when executed:

  • Creates a temporary folder within the project and initializes a bare-bones Ember project inside it.  No NPM or Bower modules are installed.
  • The Blueprint under test is generated within this temp Ember project.
  • There is now an opportunity in the code to run some synchronous tests to ensure the files are in the correct location and they contain appropriate text.
  • The Blueprint under test is then destroyed.
  • Another opportunity to check that the files were removed correctly

That looks awesome, so let’s start there.


First off we need to install these into our project and generate our test harness.

This makes a number of minor changes, including to the package.json  to add a test execution command,  and drops a test harness file into the project:

If we follow that up by trying to now test:

Then we get a bunch of errors!  But again, this is actually good news.  Notice the test is running, and the Blueprint is failing to generate code because it can’t find the foo.form.json  config file within the test Ember application.

That’s okay!  We still haven’t got around to setting up any of test fixture files at all yet.  We’ll do that shortly, but first, we’ve got a big problem here that can’t be put off.

Git commit:


Houston, We Have a Problem

Ember-cli-blueprint-test-helpers is our friend, but it doesn’t work quite the way we’d like out of the box.  By default, it spins up an Ember app, generates from the Blueprint, and allows rudimentary ‘did you generate in the right place with the right content’-type tests.  We’re looking to go one, or maybe several, steps further.  Not only do we want to generate from the Blueprint, but then launch the Ember app and execute Ember tests against the running instance.

This is where things start to get hairy.  I should also take this moment to thank Tobias Bieniek (@simplabs) – one of the main authors of the add-on – for taking some time to discuss this with me.  The Ember community is a great place, and no small reason why we love the framework.

The good news is: what we want to do is possible.

The bad news: to work it out, I had to spend a lot of time spelunking through the add-on’s source code.

The good news again: you don’t have to.

Let’s look at the key piece of the original model-test-crud.js  code:

It’s a beautiful, succinct thing, but we really need something more like:

Let’s take each of those steps in turn.

Set-up Test Fixture Data

Because at heart I’m a traditionalist, let’s go with Books and Authors.  Therefore, we’ll create a Book Model with a:

  • title (string)
  • Synopsis (string)
  • rating (number)
  • author (belongsTo Author)

The Author simply has:

  • name (string)
  • dateOfBirth (date)   

And a config file for the Book which we’ll use to build the form.  

There is a tests/dummy  folder in our project structure already which contains the structure of an Ember application.  Normally it’s used for testing Add-ons, but we can use it for storing our fixture data.

As our Blueprint doesn’t yet update the router.js  file, we’ll add that into the tests/dummy/app  folder as well with the known content:

Copy Our Fixture data

Now we have our fixture data, we need copy it into the correct place in the temporary Ember application under test.  Node has a couple of different ways to copy files, but we’re going to be copying whole folders, and for that we can use the package fs-extra .  

Our code so far now looks like this:

The tricky bit here is understanding that the setupTestHooks , amongst other things, creates the temporary folder and then moves the process’ working directory to that location.  There’s a few hours of my life I’m never getting back.

To see the full code, look at model-crud-test.js  here:


Taking Stock

We’ve covered a lot here, and it’s time to take a breather.

The great way that the ember-cli-blueprint-test-helpers have been authored allows us to do exactly what we need by just scratching below the surface.  It’s a bit disappointing this isn’t more natively supported in Ember, but maybe it’s just an opportunity for the community to step into the breach.

Next time we’ll complete the testing framework, and then follow up with actually executing some useful tests.  It’s a lot of work, but re-usable once we’ve done it.


Media Suite: A Cultural Snapshot

I tend to get one of two responses from people who ask me what I do for a living.

When I tell them I’m the Resident Anthropologist for a software development company, they tend to either look blankly at me until I qualify my statement, or they look blankly at me while pretending to understand what I said.

So, I thought it would be fitting to provide a brief overview of how anthropology can be a powerful tool in the workplace.

At a basic level, applied anthropology at Media Suite is about working with people. It’s thinking about the impact people have on business, and the impact business has on people. As a qualified anthropologist I switch between numerous functional roles that may seem disjointed from an outsider’s perspective, but fit into a seamless picture when viewing a workplace in a cultural context. This includes meeting facilitation, communication, relationship management, project leadership, research, and business storytelling – among other things. Each of these roles work toward the same goal – I pay attention to Media Suite’s culture to help aid its growth.

Of course, this begs the question – why does Media Suite place such emphasis on culture?

Media Suite wants people to enjoy their work. Happy people are more productive and more likely to bring their A-game. So Media Suite does everything it can to build a healthy, happy company culture. Although culture can’t be manufactured, we think it can be fostered.

So, how does this work at a practical level?

There are two elements:

  1. Cultural overview
  2. Doing stuff

Cultural Overview

While there is no universally agreed definition of culture, the following version has all the best bits of most definitions:

Culture – The system of shared beliefs, values, customs, behaviours, knowledge and technology that the members of a society use to cope with their world and with one another – that are transmitted from generation to generation through learning.

Schein, 1984

To understand this at a practical, real-world level, I’ve applied some Media Suite examples to to create a cultural inventory. I find the inventory to be a useful way of looking at Media Suite from an outside perspective. As an outsider we can see the organisation as a complex interconnected human system that can be tweaked to create different outcomes.


Doing Stuff

Once I have a general overview of the company’s culture, I can help shape its evolution. Here are three ways I support Media Suite’s growth:

  1. Advice: I advise decision makers on people and culture-related topics.
  2. Translation: I translate business concepts into visuals, strategies and plans.
  3. Representation: I represent company interests and manage relationships.

I’ll spare you the details of my to-do list, but here’s the basics on how cultural understanding enables advice, translation and representation of the company’s interests.

By conducting a cultural inventory, I can build a deep familiarity with the high-level view of an organisation. Learning about the history, people, processes, tools, ideologies and desired future allows me to frame the organisation as a unit with goals to be achieved. Those goals may require different outcomes from different components (people, roles, responsibilities, tools, etc.) which can then be identified, considered and addressed.

For Example:

  • Advice: When I first came to Media Suite I was asked to help conduct the Peer Review process, and offer suggestions for how we might adjust it. I started by reading through every bit of notation from previous sessions and identified common themes. I noticed that there were some consistent patterns that included a lack of consistency between personal goals which made them difficult to record, measure and possibly remember. It also seemed like there was a lot of recent growth which required some reiteration of the company’s story and plans for the future. I then interviewed team-members who had gone through each peer review session to determine what pros and cons they had experienced.

After getting feedback from the interviews I compared them with my personal observations. At this point I was prepared to offer advice for how we might adjust the peer review process to align with the company’s goals and respond to people’s feedback.  Some of the changes included reiterating the company’s vision and goals prior to each session and encouraging team-members to produce consistent, achievable goals that align with the company vision.

  • Translation: As a part of my work with the peer review process we decided that the company’s growth calls for some adjustments to the company’s messaging. So I set a recurring meeting with the Managing Director to start working through his thoughts on Media Suite’s intended future. We started by discussing how communication currently worked in the organisation, and whether or not we thought the key messages were succinct and well understood. This helped us realise that numerous individual discussions had occurred, but a more formal presentation of the company’s goals could be helpful. In response we poured ideas onto a whiteboard and mapped the relationships.

This was the first step in documenting a picture of our current position and plans for the future which could then be presented in a Learning Lunch prior to peer review sessions. This will also serve as the basis for recurring presentations. Finally, it contributed to the framework for our messaging architecture and further discussions about the way we tell our story.

  • Representation: Finally, because of my work with the company’s culture, goals and vision for growth, I’m in a position to help tell our story to new people. Some of the ways I’ve done this so far include holding conversations with the University of Canterbury regarding an internship programme. I’ve helped my colleague Kerry promote Media Suite within the Christchurch City Council at their first Smart Cities Expo. I recently manned the booth at Tech Summit with a pack of orange-shirted colleagues, and will represent Media Suite as a sponsor at GovHack’s award ceremony in Wellington.

When I meet new people they’re always interested to know what Media Suite does, and what kind of problems we solve. If I didn’t have an idea of the company as a whole unit with its history, current state and future plans I think I would struggle to answer a lot of the questions I receive. In this way I find a holistic anthropological view of the organisation quite useful.

So when I’m asked what I do for a living, and proceed to qualify what Media Suite’s Resident Anthropologist does, it sounds something like this.

“Basically, when someone’s afforded the time, tools and relationships necessary to study a company’s culture, they’ll develop a unique insight that can be mirrored to decision makers in order to validate their assumptions, spark conversation, plan for the future and encourage positive outcomes. “

So, that’s what I do.

Charity, orange Lego, and the power of the Hive

First, we looked into ordering 600 stress balls with our logo on the side. They’d be orange, obviously. Shipping costs were crazy. Plus, most people already have at least a few stress balls on their desk.

Pens? Same issues. Orange playdoh in individual tubs? Cool idea, hard to find 600 tubs of orange playdoh though. I tried.

As the Web Partner and a Gold Level sponsor for the 2017 Canterbury Tech Summit, we’d been asked to contribute some swag for the bags given to each of the 600 conference attendees when they arrived. We went through at least a dozen great ideas, trying to consider what we would like to receive in a Summit swag bag.

But, the issue we kept coming back to, was the goal. What was the goal here? Obviously we are keen to get our name out there in our industry and wider community. Media Suite does some really cool stuff, and hires really cool people and of course we want to talk about it.

The problem, was the cost. Not the financial cost, but the environmental cost and whether or not the swag was really achieving much. In the end, we decided we didn’t really want to contribute 600 items that might never see the light of day, or would sit on someone’s desk next to all the other stress balls.

So, we threw out a challenge to the wider team. How could we make our bag contribution meaningful?

This is where the power of the hive really kicks in. In half an hour on Slack, we had gone from branded pens to charitable donations. Our team was really keen to give back to some great causes. They wanted to redirect the money we would’ve spent on the pens or stress balls, and see it going to do some good.

Brilliant. But how? Anyone can give some money to charity. That bit’s pretty simple to get your head around. What we really wanted, was to give Summit attendees some skin in the game. We wanted to give people the chance to be a part of the donation process, and decide where our donations went.

Back to Slack. How could we do this? We love Z petrol station’s voting system. Every time you fill up, you get a plastic chip and you use that chip to vote for your favourite charity. It allows Z’s customers to decide which are the worthiest of causes in their community.

Could we one-up this idea? Take it to the next level? We took the voting system, and asked our team to get creative. If you were at Tech Summit, how would you want to vote?

Suggestions included empty jars, and attendees voted with a scoop of sand. Cool idea, but terribly messy and quite hard to package into a swag bag. We went through some fantastic voting chip ideas: lollies, poker chips, water, ball bearings, marbles… the list goes on.

In the end, it was one of our remote developers from Cambridge who had the winning concept. Lego.

Everyone loves Lego, right? At Media Suite, it’s all about “building the right thing”, so we liked Lego as a building tool. It comes in orange, it’s readily available, and it’s fun.

We picked three charities that do some good in the Christchurch community. Thanks to some suggestions from Canterbury Tech (summit organisers) we managed to narrow it down to three: YMCA Christchurch, Code Club Aotearoa, and Action Station. You can read more about them on their websites, or swing by our Summit booth and get the low down.

In the end, this little project ended up being a true Media Suite special, demonstrating the power of collaboration and bouncing ideas off each other to come to the best possible solution.

So, what’s the end game here?

When you walk through the doors of Tech Summit, and you receive your bag of swag, do take a moment to dig around. In there, you’ll find a little brown recycled paper bag with our logo on it. Inside the bag, is a Lego brick (in orange, of course). This brick represents a $10 donation. All you have to do, is make it count.

Visit our booth (number 5) and cast your vote. Each of our charities have a spot on the table, and each will have one Lego base plate in front of their logo. Over the course of the day, everyone who casts a vote, will do so by adding their Lego brick to the pile in front of the charity they love the most.

By the end of the day, we’re hoping some pretty cool orange Lego sculptures will rise off that table, made by all the creative, passionate folk at the Summit chipping in one brick at a time. We’re actually looking forward to seeing how these group sculptures turn out! When the Summit’s over, we will count the number of bricks in each pile, and multiply that number by $10. A donation will be made to each charity, to the value of the votes it received.

YMCA got 200 bricks? That’s a $2000 donation. With 600 swag bags in the mix, we have $6000 to give. We are hoping we will be able to give it all. This means every Summit attendee needs to add their Lego to the sculpture and make their voice heard.

So, if you’re at the Summit on Thursday, find your brick and have your say, and encourage your fellow Summit-goers to do the same. This is the only way this thing is going to have maximum impact.

In the end, it’s all up to you.


Xx The Media Suite team.