forked from jbosstm/narayana
-
Notifications
You must be signed in to change notification settings - Fork 1
/
README.txt
80 lines (66 loc) · 4.04 KB
/
README.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
#######################################################################################
#
# JBoss, Home of Professional Open Source
# Copyright 2008, JBoss Inc., and others contributors as indicated
# by the @authors tag. All rights reserved.
# See the copyright.txt in the distribution for a
# full listing of individual contributors.
# This copyrighted material is made available to anyone wishing to use,
# modify, copy, or redistribute it subject to the terms and conditions
# of the GNU Lesser General Public License, v. 2.1.
# This program is distributed in the hope that it will be useful, but WITHOUT A
# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
# You should have received a copy of the GNU Lesser General Public License,
# v.2.1 along with this distribution; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
# MA 02110-1301, USA.
#
# (C) 2008,
# @author JBoss Inc.
#
#
#######################################################################################
#
# README.txt for JBossTS QA Testsuite.
# $Id$
# @author [email protected], created 2007-02-08
This is the JBossTS QA Testsuite.
JBossTS provides distributed transaction management. The tests in the QA suite exercise
it using several processes (JVMs) for e.g. clients, servers and recovery processes. This
differs from normal unit tests that run in a single JVM. In addition the QA tests can
be long running, either because they do a lot of iterations for stress testing or because
they include realtime waits for e.g. recovery process timeouts and such. Thus running the
QA tests is a distinct step from running unit tests, which are an integral part of the build.
From July 2009, JBossTS no longer uses the DTF framework for running QA tests. Instead the
tests have been converted to junit4 and use a small scaffold to spawn the java processes
as required. This allows better use of existing tool support e.g. junit ant integration, hudson.
requires: jdk (1.9+), ant (1.9.6+), database drivers (for jdbc tests only, see build.xml)
To build the qa tests:
cd qa
ant
The test framework runs in an environment defined by the run-tests.xml script, but the test tasks i.e.
clients, servers etc, run in an environment dictated by the ./TaskImpl.properties file.
To create that file, copy TaskImpl.properties.template and name it TaskImpl.properties. Proceed to edit
the new file as required for your system e.g. location of desired jvm and such.
The tests are executed by the run-tests.xml ant script. There are various test groups, see
the script for an up to date list. For short(ish) smoke testing try
ant -f run-test.xml express
This will test the product as built by the initial product build.
To debug the test framework, see debug jvm arg in the run-test.xml junit-tests task.
To debug spawned processes, edit TaskImpl.properties to set debug command line args. You can also
enable a robust debugging mode by setting a system property tasks.remote.debug. This is set in the junit
process and will set debugging ports up incrementing from port 5000 for the first spawned process.
For jdbc tests, ensure the required drivers are present (cd qa && mvn install)
and create a suitable config/jdbc_profiles/<name_of_testnode_host>/ file by copying the existing
config/jdbc_profiles/_template/ directory or rely on the one in config/jdbc_profiles/default
By convention each test node has two accounts on each database server, with names of '<testnode_hostname>1'
and '<testnode_hostname>2'. This allows for testing of transactions with two resources. These accounts
need table creation privs plus the usual CRUD. The actual tables will be created automatically when the
tests run.
# Running a single test
There is a way to run specific QA tests. In the run-tests.xml there is a target "onetest" - it runs a
single test based on various system properties.
cd qa/
ant
ant -f run-tests.xml onetest -Dtest.name=rawresources01_1 -Dtest.methods=RawResources01_1_Test001