HTML5 Zone is brought to you in partnership with:

Paul is a principal consultant at ThoughtWorks. He is enthusiastic about open source in particular. He is known for Dependency Injection (one of its pioneers with PicoContainer), Selenium browser automation (co-founder), Branch by Abstraction and most recently Client-Side MVC frameworks. Paul is a DZone MVB and is not an employee of DZone and has posted 89 posts at DZone. You can read more from them at their website. View Full User Profile

AngularJS for Rebels: A Lower Technology Style for the Enterprise

10.25.2013
| 12001 views |
  • submit to reddit

I have been playing with a use of Angular that doesn’t follow the recommended Grunt/Bower/NPM best-practice tool-chain. The hypothesis is that many Java enterprises are not ready to go all the way down that road. It could be that developers are more comfortable with Java IDEs and build tools. It could be that the infrastructure people are not ready upgrade CI tools to be able to deal with Grunt and all that. I’m also trying to see if there’s a faster way of making Angular applications, having been part of teams that were faster with old (worse) technologies.

In this article, I outline a tier above greyhound.com’s booking service:

AngularJS with Less JavaScript

Less JavaScript was one of the goals of the experiment. If we are still having to target Internet Explorer 7 & 8, then we need to worry about overwhelming those browsers. At least we need to regression test enthusiastically every week of a project that is supposed to support it. We also have to ensure that the open source we leverage supports it too. I’ve failed already in that regard by using AngularUI, as it doesn’t support IE7. OK, whatever, lets press on with the article.

To meet the “less JavaScript” goal, I’ve tried to do less of the Angular-team recommended Services, Directives, and Modules. Instead I am sticking with a single JavaScript controller with a single list of injectable services. Don’t worry, I’m still doing separation of concerns at development time. I’m also avoiding Jasmine, which is perhaps the most controversial aspect of what I’m showcasing here. Lastly I’m not using Karma (or Protractor) for end to end testing. Instead I’ll be testing in Java, and using WebDriver (and some libraries) as mechanism to test-cover all the HTML, the JavaScript and a subset of the Java back-end itself. See Component Testing below.

I’m using TestNG, but JUnit would be just fine as an alternative to that. It could also as easily be .Net & NUnit or Ruby & RSpec too.

Bus Tickets Borrowing Greyhound.com’s Services

I’ve borrowed the “Web 1.5” app hosted on www.greyhound.com. It is currently written in .Net and uses commercial controls for some of the heavy lifting (Telerik). I’ve only delivered two components – Search Criteria, and Search Results. As this is totally unapproved usages of their services, you can’t actually buy tickets. I think if I went that far, I’d be getting a visit from the police. Greyhound could easily disable “support” for this proof of concept by checking the referrer for incoming service requests.

Run-Time Technologies

These are not a strong recommendation, it’s just what I chose to support the idea of Component Testing in a browser for a hypothetical enterprise dev team. The exercise could have been as easily done in .Net or Ruby.

Server

Client

Build-Time Technologies

My Dev Machine’s Setup

I’ve installed a DNS tool (dnsmasq) to my Mac. It allows me to map all of *.dev to 127.0.0.1. That allows me to open one page in Firefox (WebDriver) and have a different domain per test method, yet keep the same browser window open. I no longer have to worry about DOM state from one test leaking into another. I had this with ports changing in an earlier version, but figured domains was a better solution. Here’s the blog entry that speeded me through the setup for it. In the videos of the UI tests, you can see the domain name changing per test.

Other than that I’m using Jetbrains’ Intellij IDEA – the Rolls Royce of IDEs for 13 years.

Maven Acquired Dependencies:

  • FluentSelenium & ngWebDriver (I’m leading those)
    • Selenium-WebDriver (transitively)
  • Moco (award winning, and by ThoughtWorks Colleague Zheng Ye). I’m not using a released version. I’m using an unreleased (but self-buildable) version – sorry!
  • TestNG (with Guice for Dependency Injection)
  • Hamcrest for assertions
  • Decdnorator – stitches HTML / JavaScript fragments into pages (me again)
  • Maven (though could as easily be Gradle).

Note: Moco (as mentioned) will need to be git-cloned and build from root (with Gradle) if you want to run the tests yourself. Specifically check out revision 771a4e84b3e9f129391d45a854c60906d0192ee4 and build that. As soon as a release is made on the 1st Nov, I’ll flip to the released artifact.

Selenium-WebDriver as a Crutch

It was true for Selenium 1.0, and it is still a classic mistakes with WebDriver (Selenium 2.0):

1. Going through a long path to get to the component under test (CUT) – specifically login and initial landing pages
2. Being connected to the full stack for the sake of test, including known data starting positions, which up-time requirements
3. Having brittle tests because of subtleties, inconsistent timings or #3 specifically
4. Depending on Selenium to cover too much of your app, and therefore taking up too much of the total build duration

Dev teams always end up regretting too much Selenium usage.

Published at DZone with permission of Paul Hammant, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)