Backlog Aggregator: Pivotaltracker Plugin (part one)

There we are.
The goal with this plugin was to give an easy way to get from a project the stories of the current iteration.
I usually prefer to work time boxed when I play on an exploration task, so I decided to give five hours to this task and then evaluate the results and possible efforts/costs to obtain an usable version of the plugin.

My team uses Pivotatracker so I already had  the credentials to use the API, but before to write any code, I started reading a few of documentation and making some test using my REST Client.
After one hour I was sure to have enough information to start.

Starting from test, I wrote:

  • It_should_be_possible_to_get_projects_from_pivotalTracker
  • It_should_be_possible_to_get_stories_of_a_project_in_pivotalTracker

Solving this test I realized that I needed another object to Deserialize into a Model before to map it into the final DTO.

My problem was that I hadn’t found a version of the API able to give me with one call what I needed  with a JSON response.

The “{your project}/iterations/current” was perfect for my purpose, but only v5 allows you to ask for a json response and at that time v5 didn’t have this call and I haven’t found something similar.
Because I was sure that in the future they would have implemented it, I wrote these tests for my Deserializer:

  • It_should_be_possible_deserialize_stories_from_a_json
  • It_should_be_possible_deserialize_projects_from_a_json

because of what I had found about the response I added:

  • It_should_be_possible_deserialize_stories_from_a_xml
  • It_should_be_possible_deserialize_projects_from_a_xml

and then:

  • When_a_pivotal_deserializer_is_created_not_specifying_a_xml_or_json_type_an_exception_should_be_thrown

Did it work? Yes.

But the last one test had to be an alarm bell, and it wasn’t at that time, so I solved the problem following those tests.

And this is why I prefer to Pair working in TDD.
A guy writes Test, another guy solves Test.

I had a solution in my mind driven by my little trip with the REST Client, the easier one (at least, I thought so) and so the solution drove my tests.
A bad idea.

When I read my work one week later I realized the following:
From the point of view of a user I don’t care what response the API have, I don’t want to specify what kind of response I expect.
From the point of view of a user I would have wrote:

  • It_should_be_possible_deserialize_stories
  • It_should_be_possible_deserialize_projects

That’s it.
Thinking in that way I suppose I would have solved the tests implementing a “chain of responsability” pattern; maybe  in the future I’ll refactor in that way.

For now in my web app (in my test obviously I mocked this) I have these line in the web.config:

<add key="pivotaltracker:endpoint"
    value="" />
<add key="pivotaltracker:typeof" value="xml" />

The highlighted line will die.
About future, or better, about “refactoring”:

I try to follow few rules about “when to refactor”.

I refactor the code only if I have to change it and this has to happen only:

  1. because of some changes from Business side.
  2. because of some Bug
  3. because of some lack of performance

There is a fourth case, but it is so rare that it is silly to put it in my ordered list: when I’ll have time 🙂

Anyway, at the end of my time box I had a first version of the pivotal plugin and I gave it to the other team members.

One thought on “Backlog Aggregator: Pivotaltracker Plugin (part one)

  1. Pingback: Pivotaltracker plugin: Importance of Integration test | Agile. AngularJs. Asp.NET & TDD

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s