- Test Suite
- Opensphere Test Suite
- Message Detector
I defined a bunch of tests within my Opensphere project and ran them successfully on the test environment A. Now I would like to switch to test environment B and execute the same tests there as well. How can I easily adapt all parameters (i.e. JMS and database connection settings) for the new environment?
Our company uses an automated build, test and deployment framework (CI) for improving its software quality. We would like to perform Opensphere tests during the nightly build process. Can Opensphere tests be run in batch mode?
I've got JMS Message Producer component and defined a few messages that are sent to a queue. These messages become worthless if they are not processed by a specific custom program. Therefore I wanted to define the JMSExpiration header field on my messages but found out that this field cannot be edited. Is there a way to edit this field?
Opensphere is a standalone client program and does not require any server side software components in order to run.
Opensphere lets you define substitution variables on project level within a single dialog. This is useful where the same variable values are defined at several places within the project and especially also when a project at some point needs to be adapted to a different environment.
Opensphere lets you execute test suites defined in a project in batch mode from the command line. The class com.centeractive.opensphere.batch.OpensphereBatchTestRunner implements the functionality for running all active test suites within the specified project file and publishes the HTML formatted test result to the location of your choice.
Opensphere can be used for mass volume data testing but it does not produce specific metrics as you would expect from a pure performance testing tool.
The JMSExpiration header field cannot be edited manually but it is set by the JMS Message Producer when a message is sent; its value depends on the “Message Time-To-Live” field that can be defined in the property dialog of the JMS Message Producer.
You create an RV Publisher from the tool box of a folder node or test case. In its property dialog you select “Data Row Set” from the combo box labeled “Message Sending Trigger” (message send control box). Within the pop-up dialog you specify a row set that will serve as message trigger. On the messages tab of the property dialog you create a message with the desired structure. In order to have specific message field values replaced with field values from the row set, place the mouse pointer on a message field editor, press the right mouse button and select the appropriate row set column name from the pop-up menu. This will insert a substitution variable marker that gets evaluated at run time.
A message selector allows a JMS Message Consumer to be more selective about the messages that it receives from a particular topic or queue. A message selector can only use message properties and headers as criteria in conditional expressions. If a message does not comply with the specified expressions, it does not get delivered by the server. Wherever possible you should use message selectors instead of message filters.
Message filters are available for topic messages only. Defining a message filter does not reduce network traffic. When a message gets detected, Opensphere examines the whole message (including its topic) and discards it if it doesn’t comply with the filter criteria.
Every business application integrates with some kind of external resources: web services, messaging services, databases or, at least, files. While it's relatively easy to test the application with unit and component tests, high level, automated integration testing can be tricky in terms of both: development and maintenance. Openspehere addresses this problem providing variety of tools for such "black box" testing. You can find there utilities for testing communication of you app with web services, JMS producers and consumers, databases together with many other extremely useful instruments. Opensphere lets you easily create independent modules, that can talk concurrently with your program, as well as define complex test cases with specific flow. All of these have pleasant graphical form that simplifies creation and maintenance.
Probably not. Some comparisons in sample projects fail intentionally to demonstrate various situations in tests.
By default every test step within a test case is initialized before the first test step is run. On test step initialization resources are allocated and connections are made. The default behavior however, must be changed if a resource of a test step is not there, at the beginning, but is created during the test. This could be the case, if a test case creates a database that a subsequent test has to connect to, for example.
Please drop us an email on firstname.lastname@example.org.
First of all you must provide JDBC connector for your engine, it should be supplied by the database vendor. Copy the connector jar to the libext directory of your Opensphere installation. Now you can define template connection in Tool -> Tool options -> Database/JDBC. You must define driver class (e.g. "com.mysql.jdbc.Driver" for MySql), and sample URL (e.g. "jdbc:mysql://localhost/dbname" for MySql). Now, when creating new Opensphere database component, the template to use may be chosen from a list. Additionally database user name and password must be provided.
Substitution variables should be used for this. Database connection string and user credentials should be defined as variables and used throughout the project. Please note a special variable type for hiding passwords. Now, when the project is to be used on another machine, or database location changes, it's enough to modify the variables as appropriate.
They are similar to some extent. The folder can be used for atomic (standalone) program modules. All program modules can be run within a folder together by activating the run button while a folder is selected. The execution of individual program modules is not dependent on each other. The execution of program modules in a test case however, is dependent on successful execution of all preceding program nodes in the test flow chart. Test cases also have comparison program modules but folders do not. Comparison results are reported in a specific tabbed pane that is available for test cases only.
The reference table data cannot be saved to valid XML format required for the comparison. You should change your reference data query and use an appropriate field alias. Example: Instead of "select count(*) from mytable" you could use "select count(*) as count from mytable".