Latest blog entries

Erlang and Elixir Factory Lite B.A.

A brief introduction about what was the Erlang Factory Conference in Buenos Aires for some Inaka team members

Jul 07 2017 : Euen Lopez

The Art of Writing a Blogpost

The Art of Writing a Blogpost

Apr 11 2017 : Matias Vera

SpellingCI: No more spelling mistakes in your markdown flies!

Feb 14 2017 : Felipe Ripoll

Fast reverse geocoding with offline-geocoder

Do you need a blazing fast reverse geocoder? Enter offline-geocoder!

Jan 18 2017 : Roberto Romero

Using Jayme to connect to the new MongooseIM REST services

MongooseIM has RESTful services!! Here I show how you can use them in an iOS application.

Dec 13 2016 : Sergio Abraham

20 Questions, or Maybe a Few More

20 Questions, or Maybe a Few More

Nov 16 2016 : Stephanie Goldner

The Power of Meeting People

Because conferences and meetups are not just about the technical stuff.

Nov 01 2016 : Pablo Villar

Finding the right partner for your app build

Sharing some light on how it is to partner with us.

Oct 27 2016 : Inaka

Just Play my Sound

How to easily play a sound in Android

Oct 25 2016 : Giaquinta Emiliano

Opening our Guidelines to the World

We're publishing our work guidelines for the world to see.

Oct 13 2016 : Brujo Benavides

Using NIFs: the easy way

Using niffy to simplify working with NIFs on Erlang

Oct 05 2016 : Hernan Rivas Acosta

Function Naming In Swift 3

How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.

Sep 16 2016 : Pablo Villar

Jenkins automated tests for Rails

How to automatically trigger rails tests with a Jenkins job

Sep 14 2016 : Demian Sciessere

Erlang REST Server Stack

A description of our usual stack for building REST servers in Erlang

Sep 06 2016 : Brujo Benavides

Replacing JSON when talking to Erlang

Using Erlang's External Term Format

Aug 17 2016 : Hernan Rivas Acosta

Gadget + Lewis = Android Lint CI

Integrating our Android linter with Github's pull requests

Aug 04 2016 : Fernando Ramirez and Euen Lopez

Passwordless login with phoenix

Introducing how to implement passwordless login with phoenix framework

Jul 27 2016 : Thiago Borges

Beam Olympics

Our newest game to test your Beam Skills

Jul 14 2016 : Brujo Benavides


Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace


Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

See all Inaka's blog posts >>

Erlang Meta Testing

A photo of Brujo Benavides wrote this on July 17, 2015 under erlang, tdd, testing .


If you don't use tests as part of your development process, please read this article written by the great @yegor256 and then come back here once you've made the switch ;) Otherwise, this article will be almost useless for you.


A couple of years ago, Hernán Wilkinson (@hernanwilkinson) was explaining why, for Smalltalk, being a dynamically typed language was not an issue. He said something like:

You don't need types to ensure that your system works correctly. That's what tests are for! And if you want to validate that all calls to a particular method are made with the proper argument types… write a test for that!!

That methodology (writing tests to validate particular properties of your code instead of its behaviour) is what he called Meta-Testing.

In Erlang

Like Smalltalk, Erlang is also dynamically typed. Quoting Fred at Learn You Some Erlang:

every error is caught at runtime and the compiler won't always yell at you when compiling modules where things may result in failure

To cope with this feature Erlang ecosystem provides tools like xref and dialyzer. But then again, you have to either run it yourself manually or have a service (like gadget) to run them for you.

If you use those tools frequently, you'll eventually realize that they are actually written in Erlang. Which is something that's not so shocking, but what it means is that you can use those tools in your tests! You can actually do meta-testing!

Example (Using Xref)

One of best things about using those tools and the resulting tests is that they are generic. You can use the same test suite for all your systems! For example, we have the following common-test suite for Xref (implemented using xref-runner) that we use in every erlang application developed here:



-spec all() -> [xref].
all() -> [xref].

-spec xref(lsl_test_utils:config()) ->
    {comment, []}.
xref(_Config) ->
  Dirs = [filename:absname("../../ebin")],
  [] = xref_runner:check(
        #{dirs => Dirs}),
  [] = xref_runner:check(
        locals_not_used, #{dirs => Dirs}),
  [] = xref_runner:check(
        #{dirs => Dirs}),
  [] = xref_runner:check(
        deprecated_functions, #{dirs => Dirs}),
  {comment, ""}.

The only thing that might change from project to project is the list of Dirs, the rest of it stays the same.


Once you have this test in place, if you work using TDD (and you should!), no undefined function call will ever get to production and crash your app. And this applies not to a particular portion of your system, but to your system as a whole.

Bonus Track

The additional benefit of having tests like this which are so generic is that they may be applied from the very first day of your system development. Whenever you are setting up a project, regardless of how you do it, you will always start with a very basic application and not much code to test. Nevertheless, you can still make sure that your testing tools are correctly set up by just adding these tests and running them. That way, you'll be all set up for TDD from the very first commit/pull request that gets in your repo :)