code serving text serving code

Much has been said about mocks, the controversial, Swiss army knife of test doubles: Don't use them too much (source) (source) Know when to use them at all (source) Don't use them to test implementation detail (source) Don't mock types you don't own (source) Only mock classes when dealing with legacy code (source) Don't mock complex interfaces (source) (source) ...the list goes on. For a tool so easy to misuse, we're using it quite a lot. Mockito is one of the most depended-upon Java libraries in the world . While "mocking" is an abstract concept, for the remainder of this post I'll use the term mock to refer specifically to a mock or stub configured by way of a mocking library like Mockito. Likewise, when I refer to Mockito, I really mean any mocking library; Mockito just stands out because it has a welcoming API and is–no doubt as a consequence–measurably very popular. I was there too once, a frequent Mockito user, perhaps ...

"JavaScript is a beautiful and expressive language." Everybody says it, and it's true! The downside, of course, of such a flexible language is that there are 1001 ways to do everything, and not all ways are created equal. The performance (or lack thereof) of different patterns can be surprising, as well as their implementation quirks. JavaScript's various patterns for object-oriented-programming comprise an especially vibrant topic. Many JavaScript developers have their own Best Way to implement JavaScript classes and inheritance. Many others will simply use existing libraries exist to facilitate the task. I've looked at a lot of different patterns, analyzed their performance , took into account their convenience, and came up with what I think is the simplest, most practical and most performant approach. In other words, my Best Way. ;-) In analyzing performance, I'll be referencing this jsperf benchmark a number of times. At first glance it's a l...