[erlang-questions] Common Test and base applications

[Ahmed Omar]

Hi Fred,
1- How do you start the ct_slave nodes?
(ct@REDACTED)1> ct_slave:start(omarmb, testnode,[]).
{ok,testnode@REDACTED}
(ct@REDACTED)2> rpc:call('testnode@REDACTED', application,
which_applications,[]).
[{stdlib,"ERTS  CXC 138 10","1.17.5"},
 {kernel,"ERTS  CXC 138 10","2.14.5"}]

2- You can use erl_flags to specify more options to your slave node, e.g:
(ct@REDACTED)3> ct_slave:start(omarmb, testnode1,[{erl_flags, "-s mnesia"}]).
{ok,testnode1@REDACTED}
(ct@REDACTED)4> rpc:call('testnode1@REDACTED', application,
which_applications,[]).
[{mnesia,"MNESIA  CXC 138 12","4.5"},
 {stdlib,"ERTS  CXC 138 10","1.17.5"},
 {kernel,"ERTS  CXC 138 10","2.14.5"}]

On Sun, Feb 12, 2012 at 6:22 AM, Fred Hebert <mononcqc@REDACTED> wrote:

> I should specify this problem is something I noticed when using
> distributed tests based on ct_slave; I would suspect that local tests being
> run from a shell started manually do not suffer from this.
>
>
> On Sun, Feb 12, 2012 at 12:19 AM, Fred Hebert <mononcqc@REDACTED> wrote:
>
>> I've recently discovered that Common Test appears to not be starting
>> basic applications such as kernel and stdlib, but it still starts things
>> like application controllers and whatnot.
>>
>> This gives me a few problems because it breaks a few behaviours such as
>> application:which_applications(), being able to start a few applications
>> (they depend on stdlib and kernel. Sstdlib depends on kernel, and manually
>> starting kernel fails because  a bunch of processes already have that
>> name).
>>
>> It will also play negatively with things like manually calling
>> application:set_env/3 before starting an application to configure it (after
>> loading it) as just starting it will overwrite all values, etc.
>>
>> This causes me a few problems because it forces me to test everything
>> below the application level, and I can't automate testing of things like
>> distributed applications and their failover/takeover mechanisms.
>>
>> Is there any workaround for these problems?
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120212/13bf3725/attachment.htm>