Don’t Make API Calls in Tests

I recently had a great conversation about application testing strategy and remote API calls. The question we were trying to answer was this:

In an application which makes external API call, when should you mock those calls in your test suite, and when should you make live calls in your tests?

My take on this issue: always always always mock external1 API calls. Here’s why:

Continue reading Don’t Make API Calls in Tests


  1. This gets more tricky when you own both systems, but I still stand by this as a best practice for that situation as well, for slightly different reasons. 

Compiling the Best Possible Code Sample

Aspiring software engineers are often asked for code samples to demonstrate that they’ve got some clue what they’re doing. This is pretty terrifying and it’s incredibly difficult. When they’re not done well, they don’t provide much in the way of useful information.

I’m a lead engineer at a pretty cool software company. I’ve been in a lot of interviews and I’ve read a lot of crappy code samples. I decided to write about what would get me excited about a candidate’s code sample (and, by extension, them). Other people might feel differently. That’s cool; this isn’t a math test. (But I would love to hear those counter-points in the comments below!)

Continue reading Compiling the Best Possible Code Sample

Elixir Getting Started: First Impressions

I’ve worked through the Elixir getting started guide as the first step in my goal to build something in Elixir. So far, there are lots of things I like and a lot of things I find kind of strange.

The Good

The fact that Elixir is up front about the performance profiles of lists and tuples is encouraging. Understanding when certain operations will be slow helps us make good decisions about design.

The string support seems amazingly robust. The guide claims that Elixir passes every test contained in The String Type is Broken. Being able to avoid dealing with terrible string implementations is a huge benefit and, in the long run, probably worth putting up with a lot of other issues.

Parallelism is a primary concern, which is just as appealing here as it is in Go. Combined with immutability of Elixir variables, it provides an environment where you can reduce garbage collection based issues more easily.

I really like the pipe operator. Here’s a normal line of code:

Here’s that same line of code using the pipe operator instead:

The Bad

With some exceptions (like the pipe operator), the syntax is not very friendly when compared to languages like Ruby or Python. I get that some of this is probably the result of most of my experience being in imperative languages, but I just don’t find Elixir intuitive or easy to read.

This might seem like a little thing, but for most applications it is the most important thing. An employee’s time is often far more expensive than another server or ten, so languages that are harder to read have a higher “total cost of ownership” than ones where the intent is easily understood.

 

In terms of being “better” than Ruby or Rails, it still seems better in ways that Rails doesn’t concern itself with. There is a lot of interesting stuff in Elixir, though, and I’m looking forward to taking a swing at a practical project as soon as I make it through the Mix and OTP tutorials.