Example of using JavaScript Arguments and TypeScript Rest Parameters

TypeScript rest parameters are the equivalent of using arguments within a JavaScript function.

In JavaScript if you wanted to write the arguments passed to a function to the console you could write

function argumentsExample() {
    for (var i = 0; i < arguments.length; i++) {
        console.log(arguments[i]);
    };
}
argumentsExample('a'); // outputs a
argumentsExample('a', 'b', 'c'); // outputs a, b, c

This could be written like this in TypeScript using rest parameters

function argumentsExample(...inputs: any[]) {
    inputs.forEach(input => {
        console.log(input);
    });
}

which generates the following JavaScript code

function argumentsExample() {
    var inputs = [];
    for (var _i = 0; _i < (arguments.length - 0); _i++) {
        inputs[_i] = arguments[_i + 0];
    }
    inputs.forEach(function (input) {
        console.log(input);
    });
}

There’s a couple of things to note here.

  • Because the TypeScript argument is an array, the JavaScript code loops over each of the arguments and adds it into an array.
  • This enables you to use forEach which you can’t do with ‘arguments’ because it’s array like not and not an actual array!

Also don’t forget you can use all of TypeScripts’ goodness by specifying a type for the array e.g. a string

function argumentsExample(...inputs: string[]) {
    inputs.forEach(input => {
        console.log(input);
    });
}

Selling executable specifications to stakeholders, testers and developers

In this post I want to share how we made a breakthrough in using executable specifications in our latest project.

Executable specificationsExecutable specifications are scenarios created by developers, testers and stakeholders working in collaboration that check the behaviour of a system every time code is committed. For more information and a podcast about Executable specifications check out this Hanselminutes episode ‘Executable Specifications with Gojko Adzic, Jonas Bandi and Aslak Hellesoy’.

The need for change

A few months ago after joining the team, there was a lot confusion how a previous project worked.

Stakeholders weren’t sure what functionality had been implemented, testers weren’t sure if everything had been tested and developers didn’t want to go anywhere near the code.

While there was a wiki no one was sure if was 100% accurate which meant it could do more harm than good because it could lead to false assumptions.

As a result of this the relationships between the groups had suffered.

Inspired by Dan North’s talk ‘How to sell BDD to the business’ I suggested using BDD (behavior driven development) and executable specifications to help prevent this happening in the future.

Testers and business owners were open to the idea but were skeptical to how valuable it would be.

So we decided to try it out on a small part of the project.

And it worked!

Working collaboratively we found relationships started to improve and there was a lot more trust between the groups.

TickAt the end of the project stake holders, testers and developers agreed executable specifications were an excellent way to develop software and keen to adopt the approach for other projects.

So what sold executable specifications to the stakeholders, testers and developers?

  • Scenarios that matched the business problems the stakeholders wanted to solve.

    This gave stakeholders confidence and lowered fear and resistance to change.

  • Easy to read scenarios that matched the domain language the stakeholders were using.

    Stakeholders could relate to scenarios and therefore felt involved.

  • Using scenarios to fill out the blanks.

    When the test team or developers found new scenarios they communicated using with stakeholders leaving out what should happen (the then step) for them to fill in.

  • The use of tables.

    Tables allow the reader to visualise the data, reduce reputation and mean you don’t have to cram in lots of words.

    For example instead of having 

    Scenario: Submitting form with invalid password displays error
  Given I am on the registration page
  When enter the password 'a'  
  And submit the form
  Then I should see the message 'Passwords must be 8 to 16 characters long and include at least one capital letter, one lower case letter, and one number'

    and then repeating this for every permutation of invalid passwords, you can do this

    Scenario: Entering an invalid password displays error
  Given I am on the registration page
  When enter the password  
    | a						| 
	| aaaaaaaa				| 
    | AAAAAAAA				| 
	| aaaaAAAA				| 
	| 12345678				| 
	| 1234567A				| 
	| 1234567a				| 
	| 12345678aaaaaaaaA		| 
  And submit the form
  Then I should see the message 'Passwords must be 8 to 16 characters long and include at least one capital letter, one lower case letter, and one number'

    We found this gave us valuable input from stakeholders and testers who were able to come up with scenarios much faster than before.

  • Living documentation.

    Running tests to ensure the scenarios still reflected the behaviour of the system after every code change meant documentation was reliable and accurate.

The future

I’m pleased stakeholders, testers and developers have recognised the value of using BDD, scenarios and executable specifications.

By taking small steps, inspecting and adapting along the way, I hope that more projects I work on can adopt this approach.

Agile Retrospectives – A picture is worth a thousand words

A while back I went to Rachel Davies excellent ‘Inspect & Adapt with Agile Retrospectives‘ talk about agile retrospectives at a Software East.

One thing that has stuck in my head ever since has been her tip about getting people to draw a picture to represent how the sprint went.

The fact that it’s simple and easy to do is what makes it’s great.

She gave two examples, one was a group of people climbing half way up a very steep mountain and the other was a stretched limousine packed full of people without a driver.

This is definitely worth trying out in your retrospectives becuase it’s an excellent way to lighten the mood and get people contributing.

Whether you decide to keep it anonymous or not is up to you.

Here’s a drawing I’ve shown in a retrospective.

Page 1 of 2312345...1020...Last »