Directory structure for non-OTP projects

[Reto Kramer]

Tim,


> Can someone who uses the test_server please describe how they have  
> their
> development environment set up on their workstation?
>

I do use the test_server quite extensively for my development. The  
description below sound much worse than it is once you've set it all  
up ;-). Hang in there!


> Where have you
> installed erlang?
>

Regular 'make install' under /usr/local.


> Where do you put your own code in relation to that?
>

I do _not_ put my code under the /usr/local/lib/erlang/lib. I keep it  
all under some ~/ directory that I use for projects.

This caused me some trouble with the test_server initially (as I did  
not even want the test_server to be under /usr/local), but wanted the  
testserver to be "just another" application under ~/.

You can put the test_server wherever you want. In that directory  
you'll need a full blown erlang install "just" for the purpose of the  
test_server install (i.e. do a ./configure && make there).

Let's say you want the test_server under ~/foo/test_server. Install  
erlang under e.g. ~/foo/test_server/otp_src_10B-2 and untar the  
test_server src into ~/oo/test_server/otp_src_10B-2/lib/test_server.  
Then apply the change that the diff shows at the bottom of this  
message before you build the test_server as described below.

Run the following script to "install" the test_server code to you  
project test directory. The argument to the script has to be you  
_absolute_ path (otherwise the build didn't work for me) to the test  
directory of your project.

E.g. ./build_deploy /Users/reto/project/test

build_deploy:
#!/bin/bash
cd ~/foo/test_server/otp_src_R10B-2
export ERL_TOP=`pwd`
./configure
cd lib/test_server/
make release_tests TESTROOT=$1

This all has to be done only once to get your project to be in a  
position to use the test_server application.


> What do you do each time you change your code during development?
>

I have a directory structure that includes
    project/src
    project/ebin
    project/test

The project/test directory will contain a test_server directory that  
stems from the install you did further up.

The actual test code (the stuff under source code control) for my  
project is checked in under project/test/project_test. This directory  
contains the test src (.erl files) as well as the beam files for  
simplicity.

The project/test/project_test directory also contains two test_server  
control files:

project.spec:
{topcase, {dir, "../project_test"}}. % Test specification on top level

project.cover:
{include, [module_name_1,
            module_name_2]}.

The .cover file lists all modules that should be included in the  
coverage analysis.

To run tests, I invoke a Makefile from the project/test directory  
(should really do it from project/test/project_test to get rid of all  
the ..).  Something like

$ make build_tests     when tests changed
$ make run_tests       when tests or product code changed

build_tests:
         cd project_test; erlc -I ../test_server -W -o . *.erl; cd ..
TEST_EBIN=../../ebin
run_tests:
         cd test_server; erl -env TEST_EBIN ${TEST_EBIN} -s ts run  
all_tests verbose cover_details -s erlang halt; cd ..

The TEST_EBIN directory is picked up by the test_server.erl patch at  
the bottom of this message. It's needed for the test_server to work  
with code that is not under a /usr/local/lib/erlang/lib sibling to  
the test_server standard place. So TEST_EBIN points at the project  
ebin, not the test code itself. The latter is found since it's in the  
current directory when the testserver is fired up (the test_server  
picks that up all right).


Once you have all this in place, you can go trough cycles of
   - edit
   - compile project
   - make run_tests
pretty quickly.

The result is a browser window that pops up with the test results.  A  
little heavyweight maybe, but on a reasonable laptop, I turn things  
around pretty quickly using the test_server. The coverage data is an  
integral part of the report - very sweet (nicer than JUnit and Emma  
since it's more tightly integrated).

The test_server to me doesn't feel heavyweight. The install sucks  
though as you can see if you choose not to have it in the src erlang/ 
lib/test_server place and you choose not to have your projects under  
erlang/lib/project.

cheers,
- Reto



==== //depot/sdev/testserver/src/testserver/lib/test_server/src/ 
test_server.erl#2 (text) ====

358a359,361
 >           % NOTE kramer@REDACTED 2004-Oct-12 -- testserver  
otherwise can
 >           % only deal with applications/modules under the otp lib  
dir.
 >           ok = code:add_pathsa(get_ebin_paths()),
1603a1607,1631
 >
 > get_ebin_paths() ->
 >     % colon separated path list
 >     % e.g. erl -env TEST_EBIN 'a:b:c' ...
 >     case os:getenv("TEST_EBIN") of
 >       false ->
 >           [];
 >       Ebin ->
 >           % FIXME kramer@REDACTED 2004-Sep-14 -- colon is UNIX  
sepcific.
 >           % Note: use absolute pathnames throughout.
 >           PathList = string:tokens(Ebin, ":"),
 >           {ok,Cwd} = file:get_cwd(),
 >           lists:foreach(
 >             fun(P) ->
 >                     case filelib:is_dir(P) of
 >                         false ->
 >                             exit("One of the EBIN directories ("++
 >                                  P++") does not exist (cwd is "++
 >                                  Cwd++")");
 >                         true ->
 >                             ok
 >                     end
 >             end, PathList),
 >           PathList
 >     end.