<p>I have been trying to learn how to add testing to existing code -- currently reading reading <a href="https://rads.stackoverflow.com/amzn/click/com/0131177052" rel="noreferrer" rel="nofollow noreferrer">Working Effectively With Legacy Code</a>.  I have been trying to apply some of the principles in JavaScript, and now I'm trying to extract an interface.</p>

<p>In searching for creating interfaces in JavaScript, I can't find a lot -- and what I find about inheritance seems like their are several different ways.  (Some people create their own base classes to provide helpful methods to make it easier to do inheritance, some use functions, some use prototypes).</p>

<p>What's the right way?  Got a simple example for extracting an interface in JavaScript?</p>

There's no definitive
right way
, because so many people are doing so many different things..  There are many useful patterns.
Crockford
suggests that you "go with the grain", or write javascript in a way that corresponds to javascript's prototypal nature.
Of course, he goes on to show that the original model that Netscape suggested is actually broken.  He labels it "pseudoclassical", and points out a lot of the misdirection and unnecessary complexity that is involved in following that model.
He wrote the "object" function as a remedy (now known as Object.create() ).  It allows for some very powerful prototypal patterns.
It's not always easy to do develop a clean interface when you have to work with legacy javascript, especially not when you're dealing with large systems, usually including multiple libraries, and each implementing a unique style and different inheritance pattern.  In general, I'd say that the "right way" to do inheritance is the one which allows you to write a clean interface which behaves well in the context of your legacy code, but also allows you to refactor and eliminate old dependencies over time.
Considering the differences between the major library patterns, I've found that the most successful route to take in my own work is to keep my interfaces independent of the library interfaces entirely.  I'll use a library or module if it's helpful, but won't be bound to it.  This has allowed me to refactor a lot of code, phase out some libraries, and use libraries as scaffolding which can be optimized later.
Along these lines, I've written interfaces that were inspired by Crockford's parasitic inheritance pattern.  It's really a win for simplicity.
On the other side of the coin, I'm sure you could argue for picking a library, enforcing it across your team, and conforming to both its inheritance patterns and its interface conventions.