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:
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.
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.
- Plain Java Servlets/Filters
- Google’s HTTP client (needs a snappy name) – to interop with www.greyhound.com
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
- 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.