REST API Testing with Cucumber and Javascript

There are a great many tools available for testing REST Api’s by various vendors, open source plugins, browser plugins, and the old classic curl.

If you’re looking for a really simple way to test REST Api’s that is easy to maintain and entirely automated then you should consider using Cucumber with Javascript. If you’re not familiar with Cucumber, its an adapter that handles gherkin, a domain specific language for writing ATDD tests.

Here is what a simple automated test looks like using gherkin DSL:

Scenario: Making a simple GET request
    When I make a GET request to "/posts/1"
    Then The response property "userId" should be "1"
    And The response property "id" should be "1"

Any member of your team, whether it’s a developer, tester, or analyst can read and understand the scripts, which really makes it easier to collaborate as a team and eliminate confusion.

A simple POST request might look like this

Scenario: Making a POST request using tabular data
    Given The request data
    | title | body | userId |
    | foo   | bar  | 1      |
    When I make a POST request to "/posts"
    Then The response property "userId" should be "1"
    And The response property "id" should be "101"

Or if you prefer to use json (I certainly do), you can use this alternate format

Scenario: Making a POST request with json data
    Given The json request data
        "title": "foo",
        "body": "bar",
        "userId": 1
    When I make a POST request to "/posts"
    Then The response property "userId" should be "1"
    And The response property "id" should be "101"

I have written a small framework as a starting point that you can clone from Github and start writing tests today. The framework can be customized as you go along and expanded to cover any testing need you have.

Leave a comment

The Soul of a Standup Meeting

The morning standup meeting is a chance for everyone to participate in a conversation that aims to share an understanding of the current objectives, coordinate team efforts, share problems and offer help, and identify potential issues.

As a collaboration tool, it offers an opportunity for team members to sync up there work efforts by letting everyone share the work they have been doing and allowing others to ask clarifying questions and offer helpful suggestions. It is invaluable in identifying wasted effort before it happens as team members often gain valuable context during the standup meeting.

As a way to coordinate efforts, the standup meeting gives everyone an opportunity to share work that affects other team members in a way that encourages a discussion about the it, which can often alleviate any problems in the upfront.

If the work doesn’t need to be coordinated, you don’t need a team. Conversely, if you have a team, I assume the work requires coordination. Poor coordination amongst team members tends to lead to poor outcomes. – Jason Yip, It’s not Just Standing Up

Through the discussion you gain a better understanding of the ongoing work which allows the team to maintain focus on what is important, so we can provide the most value with our efforts. Teams that are not working toward a common goal will not be effective.

Productive Meetings

When team members do not get value from the morning standup meeting we hear complaints about it taking too long and wanting it to be shorter. A typical response is to do just that, make it a shorter meeting or devise a quick format so we can “get through it and get back to work”. Instead, we should be working to make the meeting more valuable!

I have always found the most enjoyable meetings are often the most productive meetings. A meeting where everyone actively discusses what’s going on often feels more like a conversation around a friends desk than a routine meeting. It’s difficult to script this sort of meeting, and the more one applies a script to it, the less enjoyable it becomes for everyone and the less they participate.

The typical three questions format attempts to get this conversation started, but when it becomes rigidly adhered to it starts to become more like “Reporting to the Leader” than a conversation and commitment to your teammates.

Jonathan Rasmussen tries to break the mold a little and I think in some ways opens up the team to more dialog as it helps to de-formalize the meeting just enough.

  • What you did to change the world yesterday?
  • How you are going to crush it today?
  • How you are going to blast through any obstacles unfortunate enough to be standing in your way?

Answering these types of questions completely changes the dynamic of the stand-up. Instead of just standing there and giving an update, you are now laying it all the line and declaring your intent to the universe.

— Jonathan Rasmusson, The Agile Samurai

Examples of Good Dialog

  • “I deployed the new database, so everyone should switch to that one today”
  • “I can’t get the vendor’s support group to return my call”
  • “The VP has asked me to work on something else for a day or two”
  • “I could use some help with my story today, I’m having a hard time with the Java code”
  • “I plan to have the UI finished and ready for QA by the end of the day”
  • “I finished writing the acceptance tests and will be done testing by the end of the day”
  • “I have a demo scheduled later this afternoon”

The above examples get right down to the heart and soul of this meeting. Commitments are clearly laid out, problems are identified, potential issues are mitigated by providing timely information and the lack of formality in the statements invites a more casual dialog in the team.

Brian Marick goes so far as to suggest the stories themselves should do the talking as they are undoubtedly the most important part of the puzzle.

“Brian’s going to keep working on me today, but he’s having trouble. He could use the help of someone who knows Hibernate.” – Brian Marick


At the end of day, the meeting is there to help the team more efficiently process the workload by having a conversation and working out any issues.

If have you have a successful standup, you should be able to answer the following questions:

  • Does you understand the current project/team goals?
  • Does you understand the value of the user stories being worked on?
  • Do we know what user stories are in progress and why?
  • Do we know of anyone not working on user stories and why?
  • Is there a plan to resolve any issues?
  • Have we identified future potential issues that we need to more closely monitor?
  • Have we identified any user stories that need extra attention?
  • Was everyone given a voice and an opportunity to participate?
Leave a comment

The Death and Life of a Programming Language

“This is dynamic! It’s great! So Simple! None of that overengineered junk!”

“I think we should add some standard utils”

“You know, we really need classes”

“Honestly, I dont know why we dont have types”

“We should really have polymorphism”

“Its a shame we cant do functional”

“This language sucks, its so bloated”

“Lets move to language X, its so much better!”

Leave a comment