GTAC 2013 Day 2 Keynote: Testable JavaScript - Architecting Your Application for Testability

Mark Trostler, Google

Testable JavaScript is a process. Whether starting with a blank slate or an already implemented application (or somewhere in-between) being able to test your JavaScript code simply, cleanly, and effectively is a necessary feature. Code that cannot be tested will be rewritten.
While JavaScript is unique due to the myriad of environments within which it runs, there are several tried and true 'testable' methodologies from other languages which also hold true for JavaScript. And of course there remain the unique challenges that JavaScript developers must face while writing and testing their code.
What patterns make code testable? Which anti-patterns hinder testing? What metrics and common sense guideposts can be used to measure the testability of our code? Once the process of creating testable code has started now what?
Join me to break down the process of writing testable JavaScript. We will investigate ideas, patterns, and methodologies that greatly increase the testability, and hence the maintainability, correctness, and longevity of your code. Whether you write client- or server-side JavaScript mastering this process will greatly enhance the quality of your code.

[download]

I think he's trying to say that using prototypal inheritance to attach interfaces to implementations doesn't make a lot of sense, and that interfaces are something that would be better enforced in documentation. For example, it would be better to write a comment showing the methods a type should implement instead of trying to inherit from an object with a bunch of no-op functions to be overridden.

[rossjones]

It's about making roles explicit. You cannot do that without interfaces.

[igorshubovych]

Great presentation!
But please @GoogleTechTalks do NOT show slides for a few seconds and then show presenter for 1 min.

[theomer]

Using interfaces make little sense when you're working with a loosely typed language such as JavaScript. The only purpose these "interfaces" (which are implemented like base classes in this talk) serve is documenting code but that's not really what interfaces were invented for.

[theomer]

In JS or any other weakly typed language, interfaces do not affect your code at all. They are nothing more than a way of documenting code for human beings. For example, in this talk, all the examples would work exactly the same even if you completely removed the interfaces.