I want to start lager before any eunit test is executed so that I can see the log when the tests are actually run (I use the log for debugging purposes).
However I have hundreds of tests (spread across multiple apps and modules) and I don't want to go through every single one and put lager:start() at the beginning so I was wondering if there is a way to tell rebar (or eunit) to execute lager:start() before executing the eunit tests?
I think you can use erl params like "-s lager", and pass it by method are described in following post.
passing runtime arguments to erlang when running rebar eunit
(I know this isn't a full answer, but I agree with Svetlin that there should be a more elegant approach... I'll offering this as an incremental improvement on Petr's answer)
If you use a Makefile with rebar, you could modify the make target to set this environment variable, it'd be something like:
$ make test
or
$ make localtest
And that target would look like:
test:
ERL_AFLAGS="-s lager"
$(REBAR) skip_deps=true eunit
Related
When using vagrant machines with test-kitchen the pre_create_command allows you to specify a command which is run locally before the vagrant machine is being created. With kitchen-docker no such configuration option seems to exist, and bending chef_omnibus_url as suggested here isn't an option.
The script specified as pre_create_command for the testing vagrants generates a local chef data bag.
Is there a solution around which I've overlooked?
Best practices include Rakefile and Thor.
In essence you control your tests from a Rakefile. For example:
rake style
This will run all commands under your style task (maybe lint/syntax/unit and kitchen tests). Of course you can modify your tasks to perform whatever you like. Here are some good resources:
https://blog.chef.io/2015/04/21/overview-of-test-driven-infrastructure-with-chef/
See the Supporting Tools and Dependencies section.
Here is an example Rakefile:
https://github.com/chef-cookbooks/chef-server/blob/master/Rakefile
I sketched a patch for kitchen-docker here. However, as the discussion on this pull request shows, there are arguments against an appropriate functionality in kitchen-docker, namely the one that such functionality (if ever) should go in the kitchen core.
So for the time being we have to live with this inconsistency between docker and vagrant, and this is where thun's answer comes into play.
This can be done using
driver_config:
provision_command: <command>
in kitchen.yml
Check more here
Kr,
Rshad
I have a common test suite and I need to perform it with rebar. Usually it is done with command
rebar ct suites=mysuite
But there is an obstacle. My suite is required configuration file and I need to specify it when I am performing tests. ct_run allows to do it with
ct_run -config <configfile>
Does anybody know how can I specify config file with rebar?
I'm looking at the source code, and it doesn't look like you can specify one by name.
It's hard coded to look in your test directory for the following files:
test.config for the -ct_config option
app.config for the -config option
If that doesn't work for you, you could probably patch it to take a rebar.config parameter instead.
Update: use rebar3 instead of rebar
Add following to rebar.config:
{ct_opts, [
{config, "./config/test.config"}
]}.
More details here.
I am using rebar, and I need to set the mnesia directory for my Erlang eunit tests (which you can usually do by doing erl -mnesia dir DIRECTORY at the cmdline). How do I run eunit tests with a special mnesia dir with rebar?
I do not think that the erl_opts section of the rebar.conf file will help because the mnesia directory is an emulator argument and I don't think it can be set through erlang. Also, I think these are options for when rebar compiles your code, not when it runs eunit tests. However, even if it did work, it will not work for me because I need to be able to set the directory dynamically (I am writing a Makefile where different targets have different db dirs).
What you actually are setting for Mnesia using erl -mnesia dir DIR is setting the environment variable for Mnesia, this can be set in the application resource file, as a switch from the command line as you have done or using a configuration file. The order in order of precedence is command line, config file and last the application resource file. An applications environment variables can also be set dynamically using application:set_env/3,4, this may not work in your case but it useful in many cases to get a particular (or even peculiar :-) ) setup for a test by setting the environment variables in the setup part of an eunit fixture.
I am in the process or learning erlang OTP and rebar and I have put together a small example app using a couple of dependencies: cowboy and lager.
I have issued
rebar get-deps
rebar compile
And things went smoothly. Now I want to fire up my console to test things around but it is not obvious to me how to start the dependency applications.
I tried issuing a
rebar generate
In order to get all the orchestration of firing up the apps, even though it's overkill for just development tests, but I miserably failed getting the following dump
Crash dump was written to: erl_crash.dump
eheap_alloc: Cannot allocate 1459620480 bytes of memory (of type "old_heap").
Aborted
The ebin dir only has beam files for the app I wrote but not the dependencies, I see the dependencies have their own ebin directory inside the main app deps directory, how would I go about having them available in a console to start them up?
I would appreciate if someone can shed some light as to what the common practice is for the dev env with multiple OTP apps.
I have read a couple of tutorials but they are mostly targeted at the rebar release cycle and not the development process.
TIA
In your case, the modules you pull into the deps directory should typically be called from within your application code - and your application can be typically invoked from the Erlang shell using the application:start/1 function. If you haven't yet, I strongly suggest that you read Chapter 12, "OTP Behaviors", of Francesco Cesarini's excellent book Erlang Programming - it's a great practical introduction for what you're attempting.
Hope everyone is doing well
I am having a problem with make files in erlang on windows. I can't seem to get the following code to work.
.SUFFIXES: .erl .beam
.erl.beam:
erlc -W $<
ERL = erl -boot start_clean
MODS = main send get loops
all: compile
${ERL} -pa 'G:\Documents and Settings\Administrador' -s main start
compile: ${MODS:%=%.beam}
clean:
rm -rf *.beam erl_crash.dump
The files I am trying to compile are main.erl send.erl get.erl loops.erl
I save the make file as an .exe
And the type
make [main]
into the windows shell
All it gives me is a wierd popup error. Is the make [main] command correct?
And is my actual code right?
Thanks for the help,
-B
Several errors here:
The indented "ERL=" line won't work right. Leading tabs are special to make. You do not have complete formatting freedom, as with some other languages.
The make file should be saved as Makefile, no extensions. Case may or may not matter to your particular "make" program. All versions of make accept Makefile, however.
The brackets on your command line will never work. I assume you're cut-and-pasting them from somewhere, but they were probably using "[main]" as an example text you're supposed to replace, including the brackets.
"make main" will also fail because you don't have a "main" target in this Makefile. "make all", "make clean" and "make compile" will work, as will several implicit targets, like "make loops.beam".
You really should get a book on make, if you're going to continue to use it. I like O'Reilly's Managing Projects with GNU Make, 3/e by Mecklenburg, available for free online or in dead tree form. The GNU make manual is also available online and as dead trees.
You probably shouldn't be using traditional "make" here, however. For purely Erlang projects, Emakefiles are shorter, clearer, and just overall better. They're not so great for building other things along side your Erlang project, but you can always do both: the Makefile uses "erl -make" to kick off the Erlang build, and does everything else itself.
Your actual code looks more or less correct. You should remove the indentation for the line starting with ERL, and make sure that all the indented lines have TAB (not SPACE) in the beginning. (Unless you have a localised version of Windows, you should check the spelling of Administrator as well.)
The name of your Makefile should be Makefile (with no file type ending at all), and you should run it with make. Just writing make in the command line will run the topmost make-command (which in your case is 'all'). If you want to run any of the other commands (or all explicitly), then just add that to your make command, like "make clean", "make foo.beam".
Also consider putting your source files in src/ and your compiled files in ebin/ since that is the Erlang standard.
I recommend this page for further information about make (if you are using GNU Make): http://www.gnu.org/software/make/manual/make.html