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.<br><br><div class="gmail_quote">

On Sun, Feb 12, 2012 at 12:19 AM, Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@gmail.com">mononcqc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>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.<br></div><div><br></div><div>


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). </div>


<div><br></div><div>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. </div>


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


<div><br></div><div>Is there any workaround for these problems?</div>
</blockquote></div><br>