I’m going to briefly outline an AngularJS project. It has stories that average one day, which is why I’m blogging. I’d like to see stories push down to hours (incl QA), and I think there’s adequate precedence in the industry for that. AngularJS is a step towards that reality, IMO.

I did help sell the project to the ThoughtWorks client (and back-of-envelope suggestions for technologies), but I didn’t staff the delivery side of the mission. I do make visits to see how they are doing, and feel I privilege to watch a team that’s zipping. This is their achievement, not mine.

Angular in a Python tool-chain.

Tool choices:

Run stack

• Python
• Flask
• Mongo (and PyMongo)
• Jekyll
• Client’s RESTful back-end (propriatary, but nameless for now)
• ElasticSearch
• PyYAML
• Beuautiful Soup
• Celery
• Invoke
• Sublime

Dev/Build/Test Stack

• Nose (it’s maker’s “is nicer testing for python”)
• Lettuce for BDD tests
• Splinter for WebDriver interop (tests)
• A Copy/paste port of bits of Protractor (via ngWebDriver) giving WebDriver Angular smarts.
• Linux VMs for Development, incl distributed file system for VMs
• Git (not Github) for source-control

How’d that go?

The team say they are mostly happy with their technology choices.

They might not choose Splinter again, over direct WebDriver and the Angular enabling snippets they pulled in to the project.

They struggled to find a sweet-spot for Lettuce (BDD tests) on a slightly slower distributed file system. There is also a tension around Selenium-WebDriver tests: they do really test, but there are challenges were debugging, maintaining, and run times of course. Targeting a three to four minute build (end to end, including selenium tests) was a goal, and meant that the team were often analyzing how things we accumulating and looking for ways to speed up stages. As always with BDD tests, you are in tension between “this would be faster/easier without BDD”, and the suspicion that you would miss them if they were gone. The evolution of the Given/When/Then grammer was led by developers, rather than by QA or BA people within the team, which is one view of a BDD holy grail.

On the Selenium-WebDriver portion of the test-pyramid, there was a willingness to hit “component tests” as much as they could. Those would not bring up stacks that contained entire backends, or that would require log-on to be repeatedly traversed through. For that category of Selenium test, they were seeing split second test times.

The app is a little more sophisticated than CRUD. It has RESTful interoperation to true backends, as well as maintaining its own models in Mongo. It also has content (Jekyll) and form generation based on YAML definitions. All in all, very far from “hello world”, and far enough to say that hitting small stories is great team achievement.

Karma / Jasmine / JavaScript testing

Angular’s own Karma framework for testing, I feel, can require a non-linear amount of effort to code for a given number of lines of JavaScript in the production code. That’s just for testing of course, in an AngularJS enabled scope. The team uses Karma, but only as a runner. If they had their time again, they’d go with Mocha. For pure JS functions you’d normally go with Jasmine, and the team did do. They actually do refactorings around the around ‘service’ seams, using Jasmine tests as the guide.

If you’re cranking up WebDriver tests at a functional level, then you’re likely testing things twice. The Angular team made Protractor as an Angular-esque accelerant on base Selenium-WebDriver functionality. I’d already copied bits of that to ngWebDriver, and they copied those bits again into their Python WebDriver classes. Towards the end, the team trialled tight component tests using WebDriver and quite liked it. Duck-Angular, by ThoughtWorkers was another alternate choice.

Node / Grunt toolchain

The team has stayed in a Python realm, and is treating the JavaScript in the page as a secondary thing, that’s just available as a side effect of Flask being started and HTML pages being requested (cashable or not). The Javascript is already modularized and the pertinent scripts specified in pages by hand. Grunt isn’t being used.

I’m mentioning this, because Grunt/Node is the AngularJS community’s recommendation. So much so, that they’ve excluded other build technology choices that corporate settings for Angular might use. I mean in terms of copyable starter/example projects.

What flavor of Agile?

It seems close to XP to me. Finger throws where two fingers is roughly one day (fibonacci style). The iteration length is one week, with ad-hoc estimation (planning game), retrospective and showcase all done in that cycle. Daily stand-ups of course, with some stakeholders calling in. Stories up for estimation are reviewed in advance by the tech lead.

ThoughtWorks does the PM, BA, Dev, QA. The product owner is from the client, as is the UX. INVEST is applied to stories, helping keep them small.

The tech lead for this project is a fellow who was on the MySupply project that hit 1.25 days per story (average) after I was, which is why I recognize the same style of XP-leaning Agile.

Did Angular specifically make the stories small?

I’ve blogged before one view of why stories can be big

• Wrong people on the team
• Wrong Technologies chosen
• Story analysis wrong
• Odious Non Functional Requirements

Back to the question, did it?

Not specifically, no. There was a lot about the team’s workflow and tacit tracking of those four that meant they were destined to have small stories.

AngularJS though, is a breath of fresh air compared to the Web 1.0 way of coding applications (where POST-redirect-GET is the high bar). It is also a significant boost or economy over other JavaScript-using approaches - vanilla JQuery and Backbone included. It means you are less likely to go down a rabbit hole when you’re doing the UI aspect of a full-stack story. There are sacrifices - you’re now in a JavaScript-only place, and you’ve abandoned Internet Explorer 6.x end-users.

There is a holy grail I think is possible too, for UX-led development with AngularJS, that makes stories even smaller perhaps, and definitely cheaper to develop. That’s for another article, though.