<p>Please excuse top posting, on phone.</p>
<p>What are the differences and pros/cons between eunit and common_test, and any good tutorials for setting up such a server as you describe?</p>
<p>I usually just use distel or ErlIDE.  Oh how I would love KDevelop integration to lessen swapping with my cpp work...</p>
<div class="gmail_quote">On Apr 15, 2011 4:19 AM, "Vlad Dumitrescu" <<a href="mailto:vladdu55@gmail.com">vladdu55@gmail.com</a>> wrote:<br type="attribution">> Hi!<br>> <br>> On Fri, Apr 15, 2011 at 12:06, Dave Challis <<a href="mailto:dsc@ecs.soton.ac.uk">dsc@ecs.soton.ac.uk</a>> wrote:<br>
> <br>>> I'm fairly new to erlang, so when I'm working on something, my development<br>>> cycle usually goes something like:<br>>><br>>> 1. Write/change code<br>>> 2. Compile using rebar / erlc<br>
>> 3. Start a shell using erl -pa ebin<br>>> 4. Paste in commands to test changes<br>>> 5. Quit shell, go to 1<br>>><br>>> Steps 3-5 usually take the longest, so I'm wondering, is there any way to<br>
>> stay in a shell, but to reset it to the default state?  I.e. the equivalent<br>>> of calling l(module_name) to load the latest version of the compiled module,<br>>> calling f() to clear all variables, and also destroying any ETS tables that<br>
>> might have been created.<br>>><br>>> Or is there some better way to test code changes from the shell after .beam<br>>> files have been recompiled while it's running?<br>>><br>>><br>
> I would strongly recommend to start using a test server - eunit or<br>> common_test are included in OTP. It really does wonders with the length of<br>> the development cycle :-) Plus it's much more reproducible and all the other<br>
> advantages of having automated tests.<br>> <br>> regards,<br>> Vlad<br></div>