Mercurial > hg > audiodb
view tests/0010/run-test.sh @ 383:6cef34d6fc48 api-inversion
Create a branch for trying to "invert" the command-line program and
library. That is, instead of having the library functions effectively
"call" the command-line client (by faking up an argv[] and abusing the
multiple constructors), have the functionality be contained in the API
function itself, and have the command-line/C++ audioDB client call those
functions.
Eventually, each API function (and perhaps tightly-focused helper
functions) will be in its own file (e.g. audiodb_create() will end up in
create.cpp), and (hopefully) the command-line client will be so trivial
as to be fully contained in a rather shortened audioDB.cpp file.
This inversion should also solve the
double-compilation-with-preprocessor-#defines of audioDB.cpp, and the
position of soap.cpp: the soap calls and their callers will be entirely
specific to the command-line binary, and will have all their hooks into
the API removed.
That's the plan, anyway. Anyone is welcome to play along.
author | mas01cr |
---|---|
date | Fri, 21 Nov 2008 15:05:56 +0000 |
parents | fe4dc39b2dd7 |
children | b09d2eb1a2b2 |
line wrap: on
line source
#! /bin/bash . ../test-utils.sh if [ -f testdb ]; then rm -f testdb; fi ${AUDIODB} -d testdb -N intstring 2 > testfeature01 floatstring 0 1 >> testfeature01 intstring 2 > testfeature10 floatstring 1 0 >> testfeature10 ${AUDIODB} -d testdb -I -f testfeature01 ${AUDIODB} -d testdb -I -f testfeature10 # sequence queries require L2NORM ${AUDIODB} -d testdb -L echo "query point (0.0,0.5)" intstring 2 > testquery floatstring 0 0.5 >> testquery ${AUDIODB} -d testdb -Q sequence -l 1 -f testquery -R 5 > testoutput echo testfeature01 1 > test-expected-output echo testfeature10 1 >> test-expected-output cmp testoutput test-expected-output ${AUDIODB} -d testdb -Q sequence -l 1 -f testquery -r 1 -R 5 > testoutput echo testfeature01 1 > test-expected-output cmp testoutput test-expected-output echo "query point (0.5,0.0)" intstring 2 > testquery floatstring 0.5 0 >> testquery # FIXME: because there's only one point in each track (and the query), # the ordering is essentially database order. We need these test # cases anyway because we need to test non-segfaulting, non-empty # results... ${AUDIODB} -d testdb -Q sequence -l 1 -f testquery -R 5 > testoutput echo testfeature01 1 > test-expected-output echo testfeature10 1 >> test-expected-output cmp testoutput test-expected-output ${AUDIODB} -d testdb -Q sequence -l 1 -f testquery -r 1 -R 5 > testoutput echo testfeature01 1 > test-expected-output cmp testoutput test-expected-output exit 104