Design, Build and Release

Ramblings of IainJMitchell on C#, Javascript and Software Craftsmanship

Introducing Pageboy.js

leave a comment

Recently, I was explaining how to Test Drive Javascript with DOM interaction and one of the audience mentioned that they found the tests unreadable. The tests had been written in qunit and used jQuery to interact with the test fixture in the DOM, here is a similar example:

test('Hello displayed When clicking on Hello button', function(){
  $('#hello').trigger('click');
  ok($('#helloDisplay').is(":visible"));
});

If you’ve used jQuery before, you should be able to decipher that this test is about clicking one element and checking the effect on another. But if you’re new to jQuery this maybe confusing, you’d have to investigate the framework and find out what the dollar ($) function did and the subsequent calls to trigger() and is(). Even experienced jQuery users might struggle to understand the meaning if there are multiple DOM interactions within the test.

So, I started to think about the possibility of creating a Domain Specific Language (DSL) to make DOM interactions in Javascript unit tests more readable. The result of this is my new open source project pageboy.js.

The inspiration for pageboy.js is the DSL that Capybara in Ruby uses to interact with the DOM. Capybara is a wrapper around DOM interaction that can be used in the step definitions in Cucumber BDD tests. The interactions with the DOM through the DSL are both concise and descriptive, which is what I want pageboy.js to aspire to be.

Once completed, the example above could be rewritten with pageboy.js as:

test('Hello displayed When clicking on Hello button', function(){
  clickButton('hello');
  ok(find('helloDisplay').isVisible);
});

For more information or to get involved visit pageboy.js on github

Written by IainJMitchell

January 13th, 2014 at 11:20 am

Posted in Uncategorized

Tagged with , ,

8 Test Driven Development tips

leave a comment

Prime
1. Have a failing test – The red stage is the first of the TDD cycle, it is complete when only one test is failing AND the test is failing on the expected assertion. Seeing the test fail is an important validation of the criteria of the test, so avoid temptation to leap into the implementation without running the tests.
Prime
2. Simplest implementation – The objective of the second (green) stage of TDD is to implement just enough to make the failing test pass. Follow a “You Ain’t Gonna Need It” (YAGNI) approach and don’t try to second guess subsequent tests.
Prime
3. Don’t forget to refactor! – The third stage of TDD is refactor, so after the simplest implementation deal with every code smell you can find, rather than batching up problems for later.
Prime
4. Delete redundant tests – Sometimes we write a test to help us get somewhere, but it may become superseded by a following test. If this is the case, delete the redundant test, it no longer has any value and may cause confusion in the future.
Prime
5. Exposing/Adding class members for testing purposes – Avoid exposing anything unnecessary on the class being tested. Typical examples of this are public flag properties introduced for easy assertions, or making a private method public to test it in isolation. Difficult to test code is a sign that it needs refactoring.
Prime
6. Don’t refactor your tests – Often tests have similar setup and so it can be tempting to use a Setup method to reduce repetition. I’d avoid doing this for two reasons: 1) There is a danger that an order dependency can build up between tests, for example test 2 will only run if test 1 sets up the class correctly; 2) It can hide the pain of using the class, for example the class might have too may dependencies. Difficult to set-up code is a sign that it needs refactoring.
Prime
7. Clear test names – The name of the test should mention the expected outcome and any preconditions, for example ‘If_there_is_no_food_Then_cat_meows‘. Writing the test name after writing the test is a good technique to achieve this.
Prime
8. TDD with a friend – pairing on TDD makes it far more enjoyable, try ping pong pairing like this:

  • Jimmy writes a failing test
  • Max make it pass in the simplest way
  • Jimmy refactors
  • Max writes a failing test… etc

Written by IainJMitchell

October 14th, 2013 at 2:00 pm

Posted in Uncategorized

Tagged with , ,

8 visualisation improvements for Kanban/Scrum boards

leave a comment

A physical Kanban or Scrum board is usually one of the first steps that software development teams take when they set sail on an Agile course. The intention of these boards is to visualise the state of the current deliverable(s), so that all members of the team and the customer should be able to understand what is happening. This may act as a conversation starter or even help pre-empt delays in delivery.

Unfortunately, many boards tend to end up as messy project task boards, which hide the subtle improvements that help reduce waste and cycle time. Think about your board, would your customer really understand what is going on?

Here are 8 easy fixes to improve Kanban or Scrum board visualisation:

Prime
1. Naming Avatars – Make sure that the Avatar includes the persons name, a few people in the office might know of your love of Optimus Prime, but for most it will cause confusion (unless you happen to be a robot that turns into truck).
readable cards
2. Card descriptions- Every card on the board should have a description that is concise and understandable to all members of the team. It should also be written/printed at a size that is readable from a reasonable distance, as this will aid stand-ups.
card rules
3. Card rules- Ensure that these simple rules are adhered to:

  • Cards in queuing columns CANNOT have Avatars on.
  • Cards in working columns MUST either have an Avatar or Blocker on, if there is no one to work on card then it is blocked.
Tumbleweed
4. Holding area for Avatars – Have an area of the board to place Avatars of people not actively working on a card. This can be split into areas such as holiday, illness, training and tumbleweed (no good reason). Having this will help identify when people are not contributing to delivery, which will in turn encourage tech debt and maintenance tasks to go through the board.
Blocker
5. Blocker visualisation- All blockers should contain:

  • The reason
  • Who marked it blocked
  • When it was blocked
Movement
6. Show movement – Place an arrow avatar on cards that have moved, these can then be removed after the standup. This helps to identify the cards that are NOT moving, which may reveal hidden blockers or encourage other team members to assist.
Rules
7. Display rules/entry criteria – If you have any rules about cards being moved from column to column, such as a ‘definition of done‘ or review, then it can help to have these rule displayed by the relevant column on the board.
Rules
8. Column space – Ensure that there is enough room in the columns for the card capacity. I’ve often seen situations where cards have had to be placed on top of each other, which has a obvious negative effect on visualisation.

Written by IainJMitchell

September 1st, 2013 at 4:48 pm

Posted in Uncategorized

Tagged with , ,

Fantasy world built of metrics?

leave a comment

Last weekend I went to see the Adam Curtis and Massive Attack event, which was part of the Manchester International Festival. This was an audio/visual film (or Glim – Gig integrating with a film) about the fake enchanting modern world which we live in today.

One of the ideas that grabbed my attention was that much of the modern world is built on numbers (or metrics), this ranges from financial planning/investments through to behaviour of political parties. The flaw in this idea is that metrics are always based upon the past actions and not the future, which leads to a future-phobic outlook and ‘safe’ decision making.

It was also mentioned that usage of metrics can also build up a fantasy world that bares no resemblance to reality, for example the financial metrics that allowed companies such Eron and Lehman Brothers to appear strong and competent.

This got me thinking about the lean/agile reliance upon metric driven development, is it possible that the more we engage in metric driven development, the more we are also entering our own fantasy world?

Yes and No.

At one of my workplaces there was an absolute obsession with Conversion Rate, if it ever went down compared to the previous year then it MUST be due to something wrong in the website. So, for instance if 100 people made a purchase on the first Saturday this year then at least 100 people should be making a purchase on the first Saturday next year. Seems logical doesn’t it?

But what if next January is much warmer and more people decide to go out rather than buying items online? Or perhaps there is a major internet outage on the Saturday that stops all of Asia accessing your site. It’s not straightforward is it?

However, a great number of development teams do not use ANY metrics, decisions on new development are made by gut feel of the owner or company ‘expert’, making it impossible to measure success. This is surely a worse situation, that brings to mind a line from Brass Eye:

“there’s no actual evidence for it, but it’s scientific fact”.

However, we must be careful to not let metrics stifle innovation, sometimes crazy ideas pay off (this company is worth over $2 million).

Written by IainJMitchell

July 18th, 2013 at 9:24 am

Posted in Uncategorized

Tagged with , ,