Tuesday, 17 July 2012

Learning how to put JavaScript together properly

After many years of trial and error / practise I feel fairly happy that I can write clean, testable .NET / C# code, which is free of any external dependencies which traditionally make unit testing harder. It's fair to say that I'm convert to TDD; having implemented it on two separate commercial projects and seen the benefits of the improved maintainability of the code base over time.

But what about Javascript? Thanks to Selenium and Specflow the functionality of those websites is pretty well tested and by default that includes any JavaScript that may be referenced in the UI tests that are run. But that's not the same as having clean testable JavaScript. Those websites have typically included a mixture of JavaScript defined in-line as well as held separately within JS files. Most functionality has been provided by individual functions attached to events and any communication introduced by coupling of functions and/or attaching attributes to FORM elements. AJAX calls and DOM updates are mixed within the application logic making isolated testing pretty much impossible, basically everything we've spent the past years learning how to avoid in our .NET code bases.

But why does this happen? Experience and reading around on the web has highlighted that the above scenario is probably still the norm, rather than the exception. Is it really that difficult to write testable JavaScript? Is JavaScript such a difficult language to learn, or does it lend itself to writing messy code? I've met some very good .NET developers who openly admit that their JavaScript code doesn't live up to their own standards.

As part of the project that I'm now working on, I decided that I'd make sure that this time would be different. I wouldn't settle for writing inline JavaScript, nor would I settle for a mishmash of unrelated functions in the global namespace all somehow working together (and when they didn't I wouldn't just use alert's and console writes to debug what was happening!). This time I was going to write testable, modular JavaScript that was easy to unit test.

As part of this experiment I'll try keeping this blog updated with our findings, including patterns and practises we find that help. An initial search of the web came up with this article (by Ben Cherry) which details his findings when he joined Twitter: Writing testable Javascript. Interestingly this article highlights a few modifications people might want to consider to some currently recommended Javascript best practises to make your code more testable, namely staying away from singletons and not enclosing too much business logic - both valid suggestions that we stay away from in our .NET code for exactly the same reasons!

No comments:

Post a Comment