inaka

Latest blog entries

/
The Art of Writing a Blogpost

The Art of Writing a Blogpost

Mar 09 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

/
Otec

Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace

/
CredoCI

Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

/
Thoughts on rebar3

Thoughts on rebar3

Jun 08 2016 : Hernán Rivas Acosta

/
See all Inaka's blog posts >>

/
Erlang Meta Testing Revisited

A photo of Brujo Benavides wrote this on November 13, 2015 under erlang, katana, testing .

How good is your Code?

2015 is coming to an end and I'm glad to say we've gone full-circle: From code to tools to code again. All with one single goal in mind: to make our code better.

We kicked this year off by introducing Gadget, which I presented at Erlang Factory SF 2015. As you can see from the presentation, Gadget is a tool that (by integrating with github using erlang-github) lets you check your code with different tools, i.e. compiler, xref, dialyzer and elvis.

The ultimate goal of it is to let you, the maintainer of an erlang app repo, have more control over the quality of the code in it.

[Meta-]Testing

One thing that's notably out of gadget's reach is testing. That responsibility still lies in the hands of the developers. At Inaka we practice TDD, so we require devs to make sure that all tests pass and (when possible) that the code coverage for the project is at 100% before issuing a pull request. But we do not require them to run dialyzer, xref, etc.: We have Gadget for that.

Nevertheless, we found that it is very convenient to be able to check all those things along with the tests, a healthy habit that also aids in the process of TDD. We even coined borrowed a name for that: Meta-Testing.

It all started with the xref_SUITE, but then Rafał Studnicki, having read the aforementioned article, came up with this great meta-testing suite that he introduced in amoc: dialyzer_SUITE.

Katana and Mixer

I'll diverge a little bit here to show you 2 libraries that will make a lot of sense in the next section:

Katana

(by Fede Carrone)

Katana is the swiss-army knife of our Erlang world. It's basically a big bag where we put everything that is used by multiple other projects but it is small enough not to deserve a whole app built just for itself.

We have our own fork which is usually up-to-date with upstream but it has its own releases, because we tend to move a little bit faster than Fede.

Mixer

(by Chef)

Mixer provides an approach to code reuse through something that (once we put our anti-flame-war shields on) we can call compile-time inheritance.

It basically lets you add functions to your modules that will do no other thing than call the same functions with the same arguments in your parent module.

We also have our own fork. This time we diverged a bit but mostly because we use erlang.mk and elvis. Functionally, both forks are the same thing.

Meta SUITE @ Katana

So, back to our original topic: We had xref_SUITE and dialyzer_SUITE and we wanted to use them in all of our projects. Now that we were at it, the only thing left was to spread elvis_SUITE everywhere, right?

So, we did what every sensible programmer would do in that situation: we copy&pasted those 3 modules everywhere

No, seriously… We used our katana!

We created a unified common_test suite with test cases for dialyzer, xref and elvis that we called ktn_meta_SUITE.

And now, combining that with mixer, you can add full meta-testing powers to your projects by just adding this module to your tests:

-module(your_meta_SUITE).

-include_lib("mixer/include/mixer.hrl").
-mixin(ktn_meta_SUITE).

-export([init_per_suite/1]).

init_per_suite(Config) ->
  [{application, your_app} | Config].

That's just the most simple version. ktn_meta_SUITE is much more flexible and you can find the whole set of options and ways to use it in its documentation section on github.

In action

Oh! Do you want to see this in action? We are already using it to play serpents. Stay tuned if you're interested in that project: A blog post about it will be written soon…

Conclusions

Finally, you can now ensure the quality of your code while you make sure it actually performs correctly. And it's neither bound to github nor bound to any particular build-tool (erlang.mk, rebar, sinan, Emakefile) that you wish to use. Everybody wins!