Test-Driving JavaScript Applications: Rapid, Confident, Maintainable Code 1st Edition

Brilliant.

The book has some great examples of how to use specific testing strategies in conjunction with JavaScript libraries and frameworks (although one of our resident JavaScript experts was a little confused about a few syntactic quirks. "Why didn't he use $syntax instead? His way is slightly confusing" came up frequently in our book club).But nearly every chapter presents a fundamental misunderstanding of what TDD is and how to apply it.TDD stands for Test Driven Design (or Development), which is a practice where you Drive the low-level Design of your program by codifying design constraints, often in the context of unit tests. You write a constraining test, watch it fail, and then write just enough production code to make the test pass. Red, Green, Refactor. If you need a high-level application architecture (which is often constrained by agents outside of simple product requirements) you can address those concerns separately; but the lower-level design is determined by the tests you write.It's actually very freeing. I've found it lets me focus on the next most important thing at all times, knowing that I'm safe to refactor the code to impart clarity or remove duplication. I don't have to worry about breaking anything; the constraints are codified in tests.This book begins every example with "Start with an Initial Design", often including sub-headings along the lines of "Design the Controller" or "Design Service Interaction". This is antithetical to how I (and other practitioners I respect) practice TDD. If we're going to design everything up front why don't we simply apply Waterfall thinking? Let's instead write a single test, watch it fail, make it pass, and refactor for clarity (I can't recall a single instance of refactoring mentioned in the book).Further, the examples have a very tight coupling of structure between tests and production code, by which I mean that every implementation file has a corresponding test file. That is certainly one way to organize your tests and code, but we've found that it leads to a great deal of difficulty if you want to refactor your implementation. Moving production code around necessarily requires moving around test code, which leads to rework trying to ensure mocks are used correctly with the new dependency structures introduced in certain refactorings.If your TDD skills are solid and you're just looking for a way to understand how tests in JavaScript might look, this book could serve you well. If your TDD skills are a little shaky or non-existent, you should definitely look elsewhere.

Venkat in this book explains that TDD is not about simply jumping into coding. Rather it is about first envisioning a design and validating / realizing that hypothesis with tests.Plus he clearly explains the various JavaScript libraries available for TDD such as Mocha, Chai, Sinon, and Protractor. This is a great book.The only request to the author is to bring out the next edition of the book as the angular chapters are little outdated now.

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.