Blog Archives

Why think when you can Tiinkk?

Posted in Agile Development, Inside TFG, iPhone

After much testing, designing and tweaking we’re excited to launch our latest mobile app, Tiinkk. We worked closely with the lads behind Tiinkk to bring their idea of a decision making app inspired by social media and crowdsourcing to life.

Tiinkk is a unique app that takes the angst out of making a decision, whether you want an opinion on which car to buy or which book to read just upload a photo or two and receive instant feedback from other Tiinkkers.

Tiinkk on an iPhone 5S

The app launch has already gained a lot of media attention, check out the links below:

The app is currently available on iOS and our team is working hard behind the scenes on an Android version.

TIBCO and The Frontier Group

Posted in Agile Development, Industry Trends, Inside TFG

Last month The Frontier Group joined the TIBCO Partner Network program and in doing so formalised an agreement that has been under development for over nine months.

This formal partnership sees us join a prestigious group of IT consulting, integration and software development companies who specialise in delivering and extending TIBCO software solutions for large enterprise customers. Collectively we have already begun solving unique problems across a variety of markets and industries with a focus on health, communication, banking and finance, government, transport and retail.

We expect to make our first project-completion announcements around oil and gas exploration, iron ore production and resource transport during Q3 2013.

The agility, focus and creativity our web application and mobile development customers have enjoyed for over a decade position us well to disrupt the stale enterprise software arena. Through this partnership with TIBCO we will deliver modern, accessible and secure applications to customers who have typically had to settle for less.

We’re very proud of this new alignment and look forward to making future announcements shortly.

ClimateWatch – iPhone app to track climate change

Posted in Agile Development, Inside TFG, iPhone

Recently we launched the iPhone app for ClimateWatch. The ClimateWatch project was developed by Earthwatch with the Bureau of Meteorology and The University of Melbourne to understand how changes in temperature and rainfall are affecting the behaviour of Australia’s plants and animals.

Components of the project built by The Frontier Group include a web application for viewing species and managing your observations, as well as an iPhone application for convenient observation recording.

The iPhone app launch has had some press which you can view with the links below:

An update for iPhone5 and an Android version are in the works.

PetRescue – the design, the rebuild and the launch

Posted in Agile Development, Inside TFG, Ruby on Rails

Earlier this year we were introduced to PetRescue, who were looking for a development company to rebuild their web application that had initially been built and tweaked over the past 8 years by one of the founders.

PetRescue is a not-for-profit organisation that finds new permanent homes for rescue pets. They are Australia’s largest on-line directory of homeless animals, and to date we have helped find new, loving families for over 140,000 pets. PetRescue started in 2004 as a small not-for-profit team dedicated to finding new homes for lost and abandoned pets, with the belief they had something to contribute to improving outcomes for rescue animals across the country.

PetRescue is a web application for both the general public looking to adopt a pet, and rescue groups around the country to list their pets for adoption. Most of the functionality is in the admin interface of the app that makes the website self sufficient, enabling rescue groups complete control over their adoption listings and process.

The PetRescue website receives ~200,000 pageviews per day and had nearly a decade of legacy data, making it a huge task to design and rebuild from the ground up, while maintaining integrity of the existing data. The app was heavily tuned for performance in the launch week, and the site also consists of import/export scripts and an API for various third party websites.

Overall the launch was a success, and PetRescue now have a much improved platform to help rehome the thousands of pets listed each month.

Visit the PetRescue website

Just Add a Dash of Include to Your Spinach

Posted in Agile Development, Inside TFG, Ruby on Rails, Tips and Tricks

Recently, I switched over from using Cucumber to Spinach in my Rails and mobile projects. I have been enjoying using Spinach so far and thought I’d share a pattern I’ve been using that seems to work for me.

Now I would like to preface this by saying that:

  • I’m not an expert on the topic
  • I’m not saying Spinach is better than Cucumber (or vice versa)

One of the things I found myself doing often when I was naming Cucumber steps was writing names that became very convoluted. I did this because Cucumber scopes all steps globally and naming two steps identically will cause the feature to fail with “Ambiguous match of “step name””. This meant I had to name almost identical steps slightly differently which would get compounded the more similar steps I had.

For example:

And I fill out the object create form with valid details
And I fill out the object create form with valid details using the google auto complete
And I fill out the object create form with valid details using the google auto complete and marking it as draft

When what I really wanted to say was:

And I fill out the form with valid details

All of that other information was covered in the feature name and/or scenario description.

When I moved to Spinach I found that I wasn’t having that problem because each feature’s steps were available only to that feature. I thought this was great… until I found myself defining identical steps in 20 different files.

My friend Tony Issakov then mentioned that you could define modules, include the Spinach DSL and share them between features. I was also warned, by my friend Jordan Maguire, that if you do this too much, you can end up with step definition files that are just includes and aren’t very readable.

For Example:

Feature: Updating an existing object

Background:
  Given I am logged in as an admin
  And there is an object in the system
  And I am on the object index page

Scenario: Successfully updating object
  When I click the object's name
  And I fill out the form with valid details
  Then I should be be on the object's show page
  And I should see the object's details have been update

Scenario: Failed to update object
  When I click the object's name
  And I fill out the form with invalid details
  Then I should see the form again
  And I should see any form errors
class UpdatingAnExistingObject < Spinach::FeatureSteps
  include SharedLinks
  include SharedPath
  include SharedForm
  include SharedObject
  include SharedViews
end

While this is an extreme example you can see that it quickly becomes difficult to know what step is defined where.

After a bit of playing around I found a happy balance between too much and too little step sharing. My general rule of thumb is to only share the following types of steps:

Authentication

module SharedAuthentication

  include Spinach::DSL

  Given 'I am logged in as an admin' do
    visit new_user_session_path
    user = FactoryGirl.create :admin
    login_with user.email, 'secret'
  end

  def login_with email, password
    fill_in 'user[email]', with: email
    fill_in 'user[password]', with: password
    click_button :submit
  end

end

Paths

module SharedPath

  include Spinach::DSL

  And 'I am on the objects index page' do
    visit objects_path
  end

  And "I am on the object's show page for my venue" do
    current_path.should == object_path(@object)
  end

  Then 'I should be on the objects index page' do
    current_path.should == objects_path
  end

end

Forms

Note that I don’t have any of the “And I fill in the form” steps in here. This is because I want separate them out and just have ‘And I fill out the form with valid details’ in my step definition.

module SharedForm

  include Spinach::DSL

  And 'I should see any form errors' do
    page.should have_css 'p.inline-errors'
  end

  def fill_in_object_edit_form attributes = nil
    if attributes.present?
      fill_in 'object[name]', with: attributes[:name]
      # fill in other attributes
    else
      fill_in 'object[name]', with: ''
    end
    click_button :submit
  end
end

Flash

module SharedFlash

  include Spinach::DSL

  And 'I should see a confirmation message' do
    page.should have_css 'p.notice'
  end

  And 'I should see a flash alert' do
    page.should have_css 'p.alert'
  end

end

Object creation

I generally like to have one per model that handles basic object creation.

module SharedObject

  include Spinach::DSL

  And 'there is object in the system' do
    @object = FactoryGirl.create :object
  end

  ## Where mk_two_object is another factory for Object
  And 'there is a mark two object in the system' do
    @mk_two_object = FactoryGirl.create :mk_two_object
  end

end

If we put it all together using the above example we get something that looks like this:
For Example:

Feature: Updating an existing object

Background:
  Given I am logged in as an admin
  And there is an object in the system
  And I am on the object index page

Scenario: Successfully updating object
  When I click the object's name
  And I fill out the form with valid details
  Then I should be be on the object's show page
  And I should see the details have been update

Scenario: Failed to update object
  When I click the object's name
  And I fill out the form with invalid details
  Then I should see the form again
  And I should see any form errors
class UpdatingAnExistingObject < Spinach::FeatureSteps
  include SharedPath
  include SharedForm
  include SharedObject
  include SharedAuthentication

  When "I click the object's name" do
    click_link @object.name
  end

  And 'I fill out the form with valid details' do
    @attributes = FactoryGirl.attributes_for :object
    fill_in_object_edit_form @attributes
  end

  And 'I should see the details have been update' do
    page.should have_content @attributes[:name]
    ## ...
  end

  And 'I fill out the form with invalid details' do
    fill_in_object_edit_form
  end

  Then 'I should see the form again' do
    page.should have_css "form#edit_object_#{@object.id}"
  end
end

Using this pattern I’ve found that I get the step separation that I was looking for in Spinach while keeping the shared functionality that I enjoyed in Cucumber.

I hope other people find this useful.

Search Posts

Featured Posts

Categories

Archives

View more archives