Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Automated testing of the mod_echo sample module with erl_mock and etap
Erlang Perl
branch: master

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
src
t
README.md
Rakefile

README.md

ejabberd_testing

Objective

This code is more of a testing strategy than direct usable code. The point was to test the etap/erl_mock combination for testing ejabberd modules. Also included as a small bonus a Rakefile used for building and installing ejabberd modules.

Dependencies

  • etap: erlang library implementing the TAP protocal

  • erl_mock: simple mocking of erlang modules.

  • ejabberd: the erlang XMPP server

  • rake: Ruby rake, for building the project (most likely already installed on your system)

Running the tests

Once you've installed all the libraries and have ejabberd deployed (but not necessarily running).

Set the following environnement variables :

  • ERL_TOP: pointing to your erlang install (/usr/local/lib/erlang)
  • EJABBERD_INSTALL: pointing to your ejabberd install (/opt/ejabberd)

Also edit the line in the test file t01_echo.t the -pz parameter to point to the ebin directory for ejabberd Once it's done :

$ rake test

You may also deploy your modules to the ejabberd install by :

$ rake install

A few notes and caveats

I guess the meat of this project is here, within those bullet points (but do give a look to the test file)

  • Most of the time, mocking ejabberd_router is the only thing you will need to do.

  • stringprep must be started if you want to use jlib and manipulate jids, which you will.

  • Don't forget to start mnesia/configure mnesia if necessary.

  • mock:calls() empties the mock call lists.

  • Very important : timer:sleep(100) in the test code after sending a message to the module. Or else the test will be ran before the call to the mock module is completed. Been bit by this one, and it stings.

  • Wrote a lot of LOCs for just testing mod_echo. I was initially hoping for something more compact. But mod_echo was not written with automated testing in mind. So my testing is quite contrived — especially in the end. There is a single modification to the ejabberd mod_echo, the ability to set the version check in ejabberd.cfg

  • I guess a couple of helper library could be extracted for building manipulation stanzas. But with exmpp around the corner, I wouldn't invest to much time on the existing jlib/xml ejabberd lib.

How to mock properly with erlang

Charpi, erl_mock's author, does not recommend the use of erl_mock.
The good, sanctionned way is to swap the pid of the "mocked" objects by the mock itself using a reverse Jedi mind trick : "This is the processes you are looking for". But that implies your library make this easy.

Final words

Is this testing strategy valid ? I think so. I have been able to test the capabilities of mod_echo which was not written with testing in mind. I expect this strategy to fare better with test-friendly code.

Help appreciated

If you spot a better (or more elegant) way to test the code, do send it my way.

License

GPL for mod_echo. BSD for my own code.

Author

mod_echo.erl by Alexey Shchepin
test code and Rakefile by Eric Cestari

Something went wrong with that request. Please try again.