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