inaka

Latest blog entries

/
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

/
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 >>

/
Testing Distributed Apps with Common Test

Carlos Andres Bolaños wrote this on December 11, 2015 under common-test, distribued-apps, erlang .

This post is about a very common scenario: how to test distributed applications in Erlang? Well, fortunately, Erlang has a remarkable testing framework: Common Test. With CT it is possible to achieve it, and the best part is that it's extremely easy.

The best way to explain how to test a distributed app with CT is with as an example, so we're going to use the project ToyKV as example. ToyKV is a simple/reduced distributed Key/Value store. In a distributed Key/Value store, reads and writes are spread across multiple KV nodes, so it would be nice to have tests that allow us to recreate this scenario, start multiple Erlang nodes running toy_kv app, and execute the provided API operations on these nodes transparently.

Because our application is distributed by nature, the issue here relies on how to spawn multiple Erlang nodes from CT. To do this, we can use the ct_slave module provided by CT. With ct_slave we can spawn multiple nodes from the CT suites.

Returning to toy_kv, what we want is to be able to start five KV nodes; we already have one, the master, which is the node from where the test suites are run, so we have to add a function in the suite to spawn the other four (a, b, c, d), and this function may be called from the init_per_suite/1 CT function.

start_slaves() ->
  Nodes = [a, b, c, d],
  start_slaves(Nodes, []).

start_slaves([], Acc) -> Acc;
start_slaves([Node | T], Acc) ->
  ErlFlags =
    "-pa ../../_build/default/lib/*/ebin " ++
    "-config ../../test/dist_test.config",
  {ok, HostNode} = ct_slave:start(Node,
    [{kill_if_fail, true},
     {monitor_master, true},
     {init_timeout, 3000},
     {startup_timeout, 3000},
     {startup_functions,
      [{toy_kv, start, []}]},
     {erl_flags, ErlFlags}]),
  ct:print(
    "\e[32m Node ~p [OK] \e[0m", [HostNode]),
  pong = net_adm:ping(HostNode),
  start_slaves(T, [HostNode | Acc]).

As it's shown in the snippet of code above, to spawn a slave node, the function ct_slave:start/2 is called. The first argument is the name of the node and the second one is an option list allowed by ct_slave. The options used in this example are:

  • {startup_functions, StartupFunctions}: here you have to specify the start function of your app, in our case is {toy_kv, start, []}.
  • {erl_flags, ErlangFlags}: here you pass the arguments to start the Erlang runtime system.
  • {kill_if_fail, KillIfFail}: specifies if the slave node should be killed in case of a timeout during initialization or startup.
  • {monitor_master, Monitor}: specifies if the slave node should be stopped in case the master node stop.
  • {init_timeout, InitTimeout}: time to wait for the node until it calls the internal callback function informing master about successful startup.
  • {startup_timeout, StartupTimeout}: time to wait until the node finishes to run the StartupFunctions.

You can check the detailed list of options HERE.

Once we call ct_slave:start/2, the node is started and the next step, which is optional, is to execute a ping to that started node, using net_adm:ping(HostNode). The ping step is done to guarantee the started node is running correctly.

Then the test cases are executed using the started KV nodes. Now we have a test recreating a real distributed scenario.

To have a better and deeper understanding about this, you can check the source code of toy_kv HERE. Within the test folder you'll find the distributed test suite dist_SUITE.erl.