Skip to main content

Test-Driving JavaScript Applications

Venkat Subramaniam
ISBN-13: 978-1680501742

I wanted to start this review simply with "Wow! Just wow!", but that’s not really going to cut it. It’s true to say that when I first learned that there was going to be a book published called "Test-Driving JavaScript Applications" I was sure it was going to be the book I had been waiting for since at least late 2007 when I was forced to write JavaScript in production for the first time. It’s publication date was pushed back and back, so it really felt like I was being made to wait. However, I wasn’t disappointed and this book was everything I hoped it would be and more.

We all know JavaScript is evil, right? Why is it evil? It’s the lack of a decent type system, the forgiving nature of the compilers and an inability to write meaningful unit tests, especially for the UI (User Interface). It’s difficult to do a huge amount about the first two points, but now JavaScript can be meaningfully unit tested, even in the UI context, with Karma, Mocha and Chai. Test coverage can be measured with Istanbul and System Tests (referred to by Subramanian as Integration Tests - this is my one bugbear with the book) written with Protractor. All of this is described in Test-Driving Java Applications.

I think it’s important to read all of part 1, Creating Automated Tests. The chapters cover everything you need to know to get started writing unit tests for both server side code and UI code, how to test asynchronous code (very important in JavaScript) and how to replace dependencies with test doubles such as fakes, stubs and spies. It’s all demonstrated with a completely test first approach with excellent commentary about how this leads to good design.

I cherry picked from part 2, Real-World Automation Testing. I was only really interested in how to write automated tests for the DOM and JQuery and how to write ‘Integration’ tests. Other chapters included how to write tests for Node.js, Express and two versions of AngularJS. The DOM and JQuery chapter was excellent showing me exactly how to take advantage of test doubles to write fully tested JavaScript without having to fire up a browser, resulting in something I can make immediate use of.

The Integrate and Test End-to-End chapter, which describes how to use Protractor, was almost enough to encourage me to abandon Java (Selenium) for System Tests and move to JavaScript. However, while looking at the latest version of Selenium, there are some other things I want to investigate first.

The final chapter, Test-Drive Your Apps is the equivalent of Pink Floyd playing Run Like Hell at the end after Comfortably Numb. It’s still good, but is really there to help you wind down from the climax and could just as easily have been omitted, but it would feel a bit odd if it was.

If there was one more thing I could get from this book it would be how to send test and coverage results to SonarQube.

If you want to use JavaScript, intend to use JavaScript or are forced to use JavaScript, get this book and automated the testing of your JavaScript.

Comments

Popular posts from this blog

Write Your Own Load Balancer: A worked Example

I was out walking with a techie friend of mine I’d not seen for a while and he asked me if I’d written anything recently. I hadn’t, other than an article on data sharing a few months before and I realised I was missing it. Well, not the writing itself, but the end result. In the last few weeks, another friend of mine, John Cricket , has been setting weekly code challenges via linkedin and his new website, https://codingchallenges.fyi/ . They were all quite interesting, but one in particular on writing load balancers appealed, so I thought I’d kill two birds with one stone and write up a worked example. You’ll find my worked example below. The challenge itself is italics and voice is that of John Crickets. The Coding Challenge https://codingchallenges.fyi/challenges/challenge-load-balancer/ Write Your Own Load Balancer This challenge is to build your own application layer load balancer. A load balancer sits in front of a group of servers and routes client requests across all of the serv

Catalina-Ant for Tomcat 7

I recently upgraded from Tomcat 6 to Tomcat 7 and all of my Ant deployment scripts stopped working. I eventually worked out why and made the necessary changes, but there doesn’t seem to be a complete description of how to use Catalina-Ant for Tomcat 7 on the web so I thought I'd write one. To start with, make sure Tomcat manager is configured for use by Catalina-Ant. Make sure that manager-script is included in the roles for one of the users in TOMCAT_HOME/conf/tomcat-users.xml . For example: <tomcat-users> <user name="admin" password="s3cr£t" roles="manager-gui, manager-script "/> </tomcat-users> Catalina-Ant for Tomcat 6 was encapsulated within a single JAR file. Catalina-Ant for Tomcat 7 requires four JAR files. One from TOMCAT_HOME/bin : tomcat-juli.jar and three from TOMCAT_HOME/lib: catalina-ant.jar tomcat-coyote.jar tomcat-util.jar There are at least three ways of making the JARs available to Ant: Copy the JARs into th

Bloodstock 2009

This year was one of the best Bloodstock s ever, which surprised me as the line up didn't look too strong. I haven't come away with a list of bands I want to buy all the albums of, but I did enjoy a lot of the performances. Insomnium[6] sound a lot like Swallow the Sun and Paradise Lost. They put on a very good show. I find a lot of old thrash bands quite boring, but Sodom[5] were quite good. They could have done with a second guitarist and the bass broke in the first song and it seemed to take ages to get it fixed. Saxon[8] gave us some some classic traditional heavy metal. Solid, as expected. The best bit was, following the guitarist standing on a monitor, Biff Bifford ripped off the sign saying "DO NOT STAND" and showed it to the audience. Once their sound was sorted, Arch Enemy[10] stole the show. They turned out not only to be the best band of the day, but of the festival, but then that's what you'd expect from Arch Enemy. Carcass[4] were very disappoin