Vagrant - simple environment provisioning

Vagrant is a tool that I'm using more and more these days.

Vagrant provides easy to configure, reproducible, and portable work environments built on top of industry-standard technology and controlled by a single consistent workflow to help maximize the productivity and flexibility of you and your team. 

To achieve its magic, Vagrant stands on the shoulders of giants. Machines are provisioned on top of VirtualBox, VMware, AWS, or any other provider. Then, industry-standard provisioning tools such as shell scripts, Chef, or Puppet, can be used to automatically install and configure software on the machine.

I use it with VirtualBox to quickly install and launch different virtual machines for both development and testing tasks. Some of the teams that I work with have used vagrant within their build process to facilitate test automation or to provide environment consistency in a delivery pipeline.

Its very easy to set up, and is similar for most operating systems

1. Install VirtualBox
2. Install Vagrant 
3. Navigate to where you want to install a vm
4. Goto a site like http://www.vagrantbox.es/ and choose a prebuilt box 
5. Then do:
   

    $ vagrant box add {title} {url}
    $ vagrant init {title}
    $ vagrant up

This will create, initialise and launch the box of your choice in VirtualBox. At point 4, you can just as easily point to your own custom built boxes.

Once you have the box built you can use the following commands to bring up, shut down, or rebuild the box

# to start the box
 $ vagrant up
# to stop the box
 $ vagrant halt
# to rebuild the box
 $ vagrant destroy --force && vagrant up

You can then bring tools like puppet into the equation to manage installations and configurations on the box.

London Tester Gathering - 20th February

Here is the prezi presentation from the talk I did at the London Tester Gathering.

Alternative views of the test pyramid diagram

warning.. there is an attempt at humour in here..

A lot of people like to use simple diagrams to explain their test approach on a project or system. One that crops a lot is the test pyramid as described in Alister Scott's WatirMelon blog. I love this diagram, and thought that it gave people a high level understanding about what and how you are going to be testing, both automatically and as a human on a project. I was wrong! After a recent series of criticism about a test strategy I produced, I realised that not everyone sees the world like I do. So here are a couple of takes on the test pyramid to help other people understand the diagram a bit better. Its so difficult to be all things to all people!

Pyramid at sunrise

Obviously, the sun is what humans do, with their minds etc.. and the pyramid describes the effort invested in certain test automation activities.

When I was looking at the diagram above, I couldn't help noticing similarities to pac-man, so here is my second attempt.

pac-man tests

For more information see my brief entry on the test pyramid.

Low ceremony http request mocking with Betamax

Whilst researching effective http request mocking in junit tests I came across a great project called Betamax created by Rob Fletcher.

Betamax is a tool for mocking external HTTP resources such as web services and RESTAPIs in your tests. The project was inspired by the VCR library for Ruby. 

You don’t want 3rd party downtime, network issues or resource constraints (such as the Twitter API’s rate limit) to break your tests. Writing custom stub web server code and configuring the application to connect to a different URI when under test is tedious and might not accurately simulate the real service. 

Betamax aims to solve these problems by intercepting HTTP connections initiated by your application and replaying previously recorded responses.

The first time a test annotated with @Betamax is run any HTTP traffic is recorded to atape and subsequent test runs will play back the recorded HTTP response from the tape without actually connecting to the external server. 

Tapes are stored to disk as YAML files and can be modified (or even created) by hand and committed to your project’s source control repository so they can be shared by other members of your team and used by your CI server. Different tests can use different tapes to simulate various response conditions. Each tape can hold multiple request/response interactions. An example tape file can be found here.

Betamax works with JUnit and Spock. Betamax is written in Groovy, but can be used to test applications written in any JVM language.

For more information please visit:

http://freeside.co/betamax

https://github.com/robfletcher/betamax

Mocking out system dependencies with MockServer

Have you ever had the problem of running a web application in a development environment that had multiple system dependencies, only to find that those dependencies are unavailable?

MockServer built by James D Bloom can help you solve this problem.

MockServer is for mocking of any system you integrate with via HTTP or HTTPS (i.e. services, web sites, etc).
MockServer supports:

• mocking of any HTTP / HTTPS response when any request is matched 

• recording requests and responses to analyse how a system behaves 

• verifying which requests and responses have been sent as part of a test

MockServer is built using Java and has bindings for both Java and Javascript although any language that can send JSON via HTTP can easily use the MockServer API. Their are some .net bindings in the pipeline, but until those come along you could use Nancy to provide similar capabilities.

For more information on MockServer please visit

http://www.mock-server.com/