Archive for January, 2013



Last friday was awesome. Leo Murillo and Carlos Fernandez, from Deiser,  were helping me out with the integration of Atlassian Jira in LiveTeamApp (my latest application for team productivity).  We spent the whole day learning about Jira integration and ended up with a nice spike containing all the information I need to develop a new version of LiveTeamApp supporting Jira. The task manager will read your Jira tasks and save the time spent back to Jira, while working with LiveTeamApp to make your current work visible in real time to your teammates.

Carlos Fernandez, Carlos Ble, Leo Murillo

Deiser is an amazing company, recently well-known for their expertise in Atlassian products and the great plugins they are building for them. Workload is one of them. If you need support on any Atlassian product, go for Deiser, these guys are experts indeed and they demonstrated that to me as we were coding together.

 

What surprised my a lot was that they spent the whole day with me just for the sake of collaboration. Just to help me to improve my application, making it more useful for Jira's users. We worked in their nice office, had a great lunch and a very productive coding/hacking day. The passion for their work is energizing. I am very grateful to Deiser's CEO, Guillermo Montoya for this nice gift, and of course to Carlos and Leo for their effort and kindness. Now some details on our work:

Integrating with Jira

At the beginning we tried OAuth as the authorization mechanism to make LiveTeamApp read Jira's tasks and add time spent to them, through the REST API. But I wasn't the easiest choice so we went for basic authentication with login/password. The authentication is sent in the http headers. This is the spike's code to retrieve user tasks using Python and Flask and the Requests library:

  1.  
  2. @app.route("/jira/listTasks/<jiraHost>")
  3. def listJiraTasks(jiraHost):
  4. url = 'http://' + jiraHost
  5. url += '/rest/api/2/search?jql=assignee=currentUser()'
  6. url += ' and resolution=Unresolved'
  7. req = requests.get(url,
  8. headers={'Authorization': 'Basic Y2FybG9zOmNhcmxvcw=='})
  9. return req.json()
  10.  

The hash in the header (Y2FybG9zOmNhcmxvcw==), is the string "username:password" base64encoded.

And this is the code to add time spent to a task:

  1.  
  2. @app.route("/jira/updateTask/<jiraHost>", methods=['POST'])
  3. def updateJiraTask(jiraHost):
  4. url = 'http://' + jiraHost + '/rest/api/2/issue/TEST-3/worklog'
  5. req = requests.post(url,
  6. headers={'Authorization': 'Basic Y2FybG9zOmNhcmxvcw==',
  7. 'Content-Type': 'application/json'},
  8. data=simplejson.dumps({
  9. "comment":"Adding Worklog thru other app",
  10. "started":"2013-01-12T10:30:18.932+0530",
  11. "timeSpent":"2d"
  12. }))
  13. return req.json()
  14.  

At the beginning we tried to do everything from JavaScript, from LiveTeamApp's client side, but due to restrictions with cross site scripting security in the browser we translated the request to the server side.

I don't have a release date for this feature to be done but it will be soon. Get ready for LiveTeamApp, you Jira user 🙂

I hope to work with Deiser's people again in the future, we had definitely a great time 😉

BDD applied to JavaScript RIAs

The big picture (click to enlarge). Drawn with LucidChart.com

 

 

Is there any difference in the implementation of Behavior Driven Development in the case of a Rich Client Application (or Rich Internet Application) ?

BDD's primary goal is communication. In that regard, there are no differences. However I see the differences in the outside-in implementation techniques.

There is no need to test the application through the GUI to make sure the specifications (customer acceptance criteria) are met.

With JavaScript we can easily test anything in the GUI with the help of the Passive View Pattern and some fine-grained integration tests against the DOM. This means that I can ensure the GUI connects with the application using unit tests + fine-grained integration tests. I can cover all the paths with automated tests, most of them unit test.

In a traditional website I can't "mock" a panel (or any other view) to check that some text has been added to it as a result of a "click" event triggered by a button. In fact, we can't use truly event oriented programming. Because the UI is just a picture,  rather than a set of objects with methods, behavior. With JavaScript this is a big advantage because we can use test doubles for those views in the unit tests, and then write contract tests to make sure those views manage the DOM properly. As a result, what in traditional web development have to be integration tests, now are unit tests.

We are back to those days where libraries to handle GUIs were so powerful and nice for both, developers and users. This time with 10+ years experience in agile testing and all kind of testing tools.

Thanks to this fact, we can design a Ports and Adapters Architecture for our application so that the GUI is just another port, at the same level than the acceptance tests. I can express the scenarios using plain JavaScript (or CoffeeScript) accessing the application through the "tests adapter",  ignoring any GUI detail.
If I use Cucumber (I am using SpecFlow right now),  my step definitions do not hit the UI. They just load the page and access the Business API (test API).

  1.  
  2. [Given(@"^I start a new task$")]
  3. public void GivenIStartANewTask(int minutes)
  4. {
  5. var browser = ScenarioContext.Current[browserKey] as IWebDriver;
  6. var navigation = browser.Navigate();
  7. navigation.GoToUrl(appUrl);
  8. var jsExecutor = browser as IJavaScriptExecutor;
  9.  
  10. // invoking my JavaScript Business API here
  11. var invoked = (string)js.ExecuteScript(
  12. "return app.startNewTask();");
  13.  
  14. // making sure the Business API got the call
  15. invoked.Should().Be("newTaskCreated");
  16. }
  17.  

The "Should" comes from FluentAssertions. The browser is Webdriver (Selenium).
If I don't user Cucumber, another option is to directly write the scenario with CoffeeScript.

  1. describe "LiveTeamApp: the team productivity application", ->
  2. beforeEach ->
  3. loadApp(appAddress, initTests)
  4.  
  5. describe "the tasks management system", ->
  6. it "counts the time consumed by every task", ->
  7. app.startNewTask()
  8. waits two.seconds
  9. app.finishCurrentTask()
  10. app.lastFinishedTask.elapsedSeconds.should.equal(2)

This is Jasmine plus  Chai's syntactic sugar (should).
This scenario is actual code from my application LiveTeamApp.com, which has been developed entirely following this process (please check it out with your team, I believe you will like it 😉

Notice how I am writing a programmatic interface (the test adapter) to talk to the application with the language of the domain.  

For asynchronous cases, I am writing a small fluent API called Flas, which uses Gherkin to encapsulate blocks containing jQuery ajax requests. The Given-When-Then blocks scope asynchronous calls so that every block is executed once the calls have finished.

For more complex scenarios where I need several instances of the application at the same time (to design and test how users interact with each other), I am using CasperJS. This the case of LiveTeamApp's chat service, where users can chat with each other and also chat with the whole team. The acceptance criteria has been written with CasperJs to open several browsers and use the programmatic API from all of them to interact. Again, no need to hit the GUI in those acceptance tests.

My friend Ivan Stepaniuk and I presented this work and ideas first in Agile Testing Days 2012. Since them I am improving my technique, to write better and better acceptance tests.

The workshop

If you want to learn more and practice the technique, I encourage you to attend to my workshop. In the workshop you practice the whole BDD cycle, from the specifications workshop to the views implementation. See more information about the workshop in this post.

The book

I am starting to write a book on this. If you want to help me out with it please let me know. I expect it to be published in late 2013 or 2014. There is a great book on TDD with JavaScript written by Christian Johansen. It covers thoroughly all you need to get started with JavaScript and TDD as well as advanced topics. I'll try to write my book as a complement to Christian's. My TDD style is a bit different from Christian's but my motivation to write the book is not because of that, but to show readers the whole BDD cycle in a rich client application.
I won't repeat the great lessons you can read in  The Cucumber Book which is a must-read. Even if you are not using Cucumber, Matt's and Aslak's book is fantastic to learn BDD.
The other books I would expect my readers to read before, are the ones by Gojko Adzic on Briding the Communication Gap and Specification by Example 🙂

 

jQuery UI draggable is so cool! However, if the draggable element (or any of its children) contains a scroll bar, clicking on it will result in the mouse pointer stuck on the whole draggable element forever. To avoid that, use the "cancel" option:

  1.  
  2. $('#theDraggable').draggable({
  3. cancel: "input, textarea, .someClass"
  4. });
  5.  

 
And it will work perfectly 🙂

At the time of this writing, I am using jQueryUI 1.8 version.

This year I will tour Europe with my new workshop: Behavior Driven Development for Rich Internet Applications using JavaScript.

Who is this workshop for?

JavaScript developers.  This is a workshop for those developers who already have some experience with TDD and JavaScript. I will not explain what an automated test is, I expect attendees to be familiar with the notion of test-first development. However, you don't have to be a TDD expert to join the workshop. Some experience with test doubles (mock, stubs...) will help, although we will review them in their JavaScript version.
Attendees must be familiar with dynamic languages and must have a good JavaScript knowledge. Although a deep knowledge of the JavaScript language is not required, it is important to be used to the language, at least practicing code katas. I have prepared these exercises to make sure we all can expect a certain level of JavaScript knowledge. I help with any doubts on those exercises.
Important: Aim of this workshop is to teach developers how to develop rich client applications, not a website with some JavaScript on it. Mobile apps based on JavaScript fall into this category.

Workshop contents

BDD is a full stack methodology. In this other post you can read how I am implementing BDD for RIAs. We will develop several user stories from the ground up, starting from the specification workshop and ending with working software.  This is the table of contents:

  • Communication: some advise for effective communication and productivity.
  • Specification workshop: requirements and business value.
  • Agile JavaScript infrastructure: everything we need to get started.
  • Cucumber and its many flavors: examples with cucumber.js and SpecFlow
  • Event oriented programming.
  • Testing techniques with JavaScript and test doubles.
  • Most common design patterns: ports and adapters, passive view, observer, factory, singleton.
  • Architecture: those other things that don't emerge from the design but have to be thought upfront.

Everything is practical. Attendees work in pairs, rotating every now and then to be able to pair up with at least four people. Pair programming is explained in the workshop and I am facilitating and helping pairs all the time. We stop after each exercise to add some theoretical notes and recaps.

Why JavaScript?

I used to think that JavaScript was something terrible,  even worse than PHP 🙂 But it is no longer like that (PHP has also improved!). The JavaScript platform is so powerful these days. It's quite mature and evolving very fast. Mainly because browsers are improving a lot. Even our good friend IE, is negotiation a truce with developers in its latest versions.

Desktop applications were so powerful back in the 90's regarding the user experience and the programming techniques. The web as it came in the 2000 decade, was a step back in terms of tooling and user experience but it was a huge advantage in terms of deployment. Now we can leverage everything that has been effective in the past 20 years: rich user experience,  powerful programming techniques and tools, agile testing, and high market potential (web and mobile). JavaScript platform means to me the JavaScript language and also CoffeeScript and any other language which compiles into JavaScript.

Is BDD different for JavaScript?

Not really from the high level. However, rich client applications are now easier to test than ever. What in traditional web development are integration tests, now can be turned into unit tests, making maintenance much more efficient. The actual instances of the objects in our application are directly accessible in our tests, there is not need to hit the application through the GUI to run end to end tests.
The amount of glue code or automation code can be reduced or even removed in some cases. It is worth understanding the differences to take advantage of rich client side development.

Should you attend this workshop?

This is a career investment. If you don't expect to practice any learned lesson from the workshop, better you save your money. On the other hand, if you come to the workshop willing to learn, ask and practice, this workshop will save you a lot of time, effort and mistakes.  Every time I invest my money in training I try to calculate the ROI somehow and have a clear reason as to why am I doing that investment.

In this workshop you will understand the best practices that took me years (and pain) to learn. You will be ready to apply them in your upcoming projects. It is impossible for you to master all the techniques after a single day but you will get a solid foundation to start from and knowledge to avoid critical mistakes.

Is there any sample application developed this way?

Yes there is! 🙂 Check it out for free at LiveTeamApp.com, my latest and coolest application for team productivity.

The bonus

When you enroll on the workshop you also get homework and homework help. You can send me any questions you have, anytime. You also get access to a mailing list where you can get new exercises, news, and more. Because I don't just want attendees for the workshop, I want people to learn so I'll help you keep on learning.

You can buy your ticket now

The next edition will be in Postdam, Germany. It will be part of AgileDevPractices (March 4, 2013). Following editions will be published here (look in the right-hand sidebar). If you would like to host the workshop in your city, please contact me.
Pricing: Early Bird 750€, Regular 850€.  Buy Now

Tell me more

Do you want to know where and when is the next workshop edition? Join the mailing list. You will not receive any spam, I promise 😉