Date: Fri, 29 Mar 2024 13:36:36 +0100 (CET) Message-ID: <408332328.161.1711715796461@vmisdata19.uni-oldenburg.de> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_160_1529451490.1711715796460" ------=_Part_160_1529451490.1711715796460 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
New: Testing can now be done with mvn, too. Detailled informatio= n will follow. Here some short hints
mvn cle= an verify -Ptest,solobuild,currentOS -Dtargetfilename=3D${PLATFORMTARGETFIL= E} =20 // change to dir, where product is placed (here linux example) = =20 cd ${WORKSPACE}/odysseus_dev/test/test.product/target/products/de.uniol.inf= .is.odysseus.test.runner.product/linux/gtk/x86_64/ // run test java -Dosgi.requiredJavaVersion=3D1.8 -Xms1024m -Xmx1024m -jar plugins/org.= eclipse.equinox.launcher_1.4.0.v20161219-1356.jar
See PLATFORMTARGETFILE = for further information about targetfilename.
In combination with our build tooling (Jenkins), we are running some int= egration tests for checking Odysseus functionalities. After each hourly bui= ld a certain server product is built and run. This instance is used for dif= ferent sets of queries (and sometimes some expected output) to test differe= nt things like query languages, the executor or operators. This article sho= ws the currently existing test components and how a new component can be in= tegrated.
The basic stuff for the integration testing can be found in the bundle c= alled de.uniol.inf.is.odysseus.test. It contains the runner that executes t= he tests and some reusable abstract classes that can be used for own test c= omponents.
The structure of the testing is as follows. There is a test-application = that binds different test components (implementations of ITestComponent) vi= a a declarative service and executes them. Each test component may have any= number of so called "sub tests". For example, the nexmark-test is a test c= omponent with 5 queries. Each query is a subtest and is tested for its own.= However, if one sub test fails, then the whole test component fails too. T= here are already some test components with a certain functionality that are= explained in the following section. A sub test is bundled into a "test set= ". There are different test sets depending on the type of the test componen= t. For a query test component, for example, there is a query test set that = contains a query that should be executed. An "expected output test componen= t" (which checks if the results of the query matches to an expected list of= tuples) uses an "expected output test set" instead to combine a query to a= certain expected output.
Furthermore, there is the possibility to manage a context. This can be u= sed, for example, to run the same tests with a different context. A predefi= ned basic context holds the current user (which is the "System" user) and t= he data-root-path (which is by default the root of the bundle). However, yo= u may use this, e.g. to run the same tests with different users.
There is a TestRunnerProduct which can be used to run the test in Eclips= e.
There are some basic concepts for adding new queries:
We use the Test-Component under to the bundle: de.unol.inf.is.odys=
seus.test.component.operator
Here you can find the folder: testdaten containing tests.
First, you have to define a new input data set. In most cases, the easie= st way would be a CSV file. It can be copied from other tests. We use input= 0.csv from the aggregate_time test
Second, you have to define a new query. This should be done in Odysseus Studio.In our Example w= e use: window_sliding.qry
///Odys= seusScript #PARSER PQL #TRANSCFG Standard #RUNQUERY percentage =3D ACCESS({ source=3D'percentage',=20 wrapper=3D'GenericPull', transport=3D'file',=20 protocol=3D'SimpleCSV', dataHandler=3D'Tuple',=20 options=3D[ ['filename', '${WORKSPACEPROJECT}\input0.csv'],=20 ['csv.delimiter', ';'], ['csv.trim', 'true'] ],=20 schema=3D[ ['timestamp', 'STARTTIMESTAMP'],=20 ['percentage', 'INTEGER'] ]}) window0 =3D window({size =3D 1, type =3D 'time'}, percentage)
Here we test a simple window, that creates windows of 1 millisecond.
Start the query and look if everything compiles correct. When the query = terminates use Show Stream Elements - List - Show all last elements on the = query and let the query run again.
YOU SHOULD NOW CAREFULLY CHECK THE RESULT. IS THIS THE OUTPUT YO= U EXPECT. This step is very important, else the test makes no sense!
If everthings seems ok, copy the whole ouput of the list window and past= e it into a file window_sliding.csv.
Now go to the testbundle: de.unol.inf.is.odysseus.test.component.o=
perator
Change in windows_sliding.qry the filename as follows: ['filename'=
, '${BUNDLE-ROOT}\testdaten\window_sliding\input0.csv']
This test is now part of the test suite and will be run each time, the t= est components run.
Some remarks for the testing behavior.
This test tries to execute queries, but does not check any processing re= sults. Therefore, this test is used for testing query languages, for exampl= e, to check if the syntax is still ok and a query plan can be built by the = parser. To add your own tests, simply add a qry-file within the bundles sub= folder called "testdata".
This test starts nexmark (not by using the generator but using dedicated= files) and runs different queries. Furthermore, it checks, if the result o= f a query matches to a given expected output. Its behavior is very similar = to the "operator test component" by running a query and testing the results= of the query with an expected output. For example, the query1.qry is execu= ted and the test component checks, if the results are (semantically) equal = to the given expected output query1.csv. You can extend this by adding new = pairs like query6.qry/query6.csv to testdata and change the NexmarkTestComp= onent class - the method createTestSets must be changed to return the new t= est set (the query6 pair).
This test has very short queries, because it only tests a single operato= r (or some more if they are needed - like windows for aggregations :laugh:)= . Each sub folder corresponds to a sub test and each sub test is a pair of = the query and the expected output. The folder is searched recursively for n= ew pairs, so you may simply add a new subfolder with a pair of qry- and csv= -file to create a new operator-test or you can use the Testcase Generator to create a new test ca= se for an operator.
This test checks if the k= ey value operators work and have the expected results. For now key valu= e project and select and the keyvaluetotuple and tupletokeyvalue operators = are tested. The input and output data is given as json files.
This test checks the operators and transformation rule of the probabilistic feature. The te= st consists of all relational operators and tests for the correct estimatio= n of stochastic models.
This test checks reported issues. Each test is named after a JIRA issue = to make sure the reported issue remains fixed in future releases.
To add your own test component you have to do the following:
de=
.uniol.inf.is.odysseus.test.feature
.