Is it only possible to test the data with JXUnit, or can we call and test the methodes from the programs we wrote?
How do we test a database connection?
What's the relation between JXUnit and JUnit? Is it correct that with JUnit we can test the program and with JXUnit we test only the data?
Where can I found an explanation of this keywords used in jxu-files (set, absolute, regexp, subst, indirect, ...?
<jxu>
<set name="absoluteTestName" value="a"/>
<absolute name="compareFile1" dir="compare" value="absoluteTestName" indirect="true" />
<save name="compareFile1" file="x.txt"/>
<set name="compareFile2" value="c:\jxunit3.3\src\net\sourceforge\jxunit\compare\"/>
<subst name="compareFile2" regexp="$" value="absoluteTestName" indirect="true" />
<save name="compareFile2" file="y.txt"/>
Here is an excerpt from a paper I wrote on JXUnit. It doesn't explain your specific questions but it does suggest a way to create your own custom JXUnit tests.
/****************************************/
Limitations of JUnit
Although the JUnit framework is very powerful, creating unit tests for interdependent components is difficult. This difficulty increases proportionally to the complexity of the system. The main problem with implementing reusable test components in JUnit is the tight coupling between test data and test logic. A developer can work around these problems by creating intelligent “setup” and “teardown” methods, but it makes creating the tests more difficult. Often the developer of the particular JUnit test is not familiar with all of the dependencies between components. The end result is a test that isn’t very reusable or isn’t implemented at all.
JXUnit Introduction
JXUnit tries to resolve some of these JUnit issues by separating the data from the test logic. JXUnit comes with a suite of common tests that can be used (e.g. isEqual, eval, save, etc. see Refereces section for more details). The framework runs on a directory-based structure where configuration files are create in a directory and executed recursively by the framework (i.e. The JUnit TestRunner program). Specifically, all JXUnit tests are started when TestRunner finds a “test.jxu” file in a directory. Each test.jxu file represents a test case and since there is one unique test.jxu file per directory, a directory represents a test case.
Creating Your Own JXUnit Tests
I have created a generic extension to the JXUnit framework to help developers create their own custom JXUnit tests. The generic extension is conveniently called JXGeneric. Developers create their own custom tests by simply extending the JXGeneric class. The XML format for running a JXGeneric test is the following:
<generic name="Your Custom Test Class Name" config="config file"
dir=” some directory” message=”some message” />
“name” is the only required attribute in an generic element. The remaining attributes are optional and can be used by the test developer. Here is an example of a test.jxu file listing several hypothetical JXGeneric programs:
The above configuration is hypothetical and could be implemented many different ways, but it illustrates how a test could be configured. In the above example, the first JXGeneric test is responsible for creating a system user. The second test creates the users account. The TestAccountCalculation class is the primary test run in this configuration. It’s responsible to verify that the account calculations for the system are correct for the given configuration (i.e. accountTransactions.xml). The remaining tests, RemoveUserAccount and RemoveUser are responsible for cleaning up the executed test. These cleanup tests could be combined with the CreateUser and CreateUserAccount with their respective configuration files defining the action (create or cleanup) that should take place in the test.
What makes this framework so useful is that you no longer need to code all the setup procedures in your individual JUnit tests. The setup procedures can now be specified as individual steps in you test.jxu file. And these procedures can be used over and over again. The framework also makes it possible for a developer to run the complete set of tests without knowing the details of each test. A directory structure of tests can be created and shared with each developer. This makes it easier to find defects early in the development cycle.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is it only possible to test the data with JXUnit, or can we call and test the methodes from the programs we wrote?
How do we test a database connection?
What's the relation between JXUnit and JUnit? Is it correct that with JUnit we can test the program and with JXUnit we test only the data?
Where can I found an explanation of this keywords used in jxu-files (set, absolute, regexp, subst, indirect, ...?
<jxu>
<set name="absoluteTestName" value="a"/>
<absolute name="compareFile1" dir="compare" value="absoluteTestName" indirect="true" />
<save name="compareFile1" file="x.txt"/>
<set name="compareFile2" value="c:\jxunit3.3\src\net\sourceforge\jxunit\compare\"/>
<subst name="compareFile2" regexp="$" value="absoluteTestName" indirect="true" />
<save name="compareFile2" file="y.txt"/>
<isEqual name="compareFile1" value="compareFile2" indirect="true" message="compareFile1 != compareFile2" />
</jxu>
Here is an excerpt from a paper I wrote on JXUnit. It doesn't explain your specific questions but it does suggest a way to create your own custom JXUnit tests.
/****************************************/
Limitations of JUnit
Although the JUnit framework is very powerful, creating unit tests for interdependent components is difficult. This difficulty increases proportionally to the complexity of the system. The main problem with implementing reusable test components in JUnit is the tight coupling between test data and test logic. A developer can work around these problems by creating intelligent “setup” and “teardown” methods, but it makes creating the tests more difficult. Often the developer of the particular JUnit test is not familiar with all of the dependencies between components. The end result is a test that isn’t very reusable or isn’t implemented at all.
JXUnit Introduction
JXUnit tries to resolve some of these JUnit issues by separating the data from the test logic. JXUnit comes with a suite of common tests that can be used (e.g. isEqual, eval, save, etc. see Refereces section for more details). The framework runs on a directory-based structure where configuration files are create in a directory and executed recursively by the framework (i.e. The JUnit TestRunner program). Specifically, all JXUnit tests are started when TestRunner finds a “test.jxu” file in a directory. Each test.jxu file represents a test case and since there is one unique test.jxu file per directory, a directory represents a test case.
Creating Your Own JXUnit Tests
I have created a generic extension to the JXUnit framework to help developers create their own custom JXUnit tests. The generic extension is conveniently called JXGeneric. Developers create their own custom tests by simply extending the JXGeneric class. The XML format for running a JXGeneric test is the following:
<generic name="Your Custom Test Class Name" config="config file"
dir=” some directory” message=”some message” />
“name” is the only required attribute in an generic element. The remaining attributes are optional and can be used by the test developer. Here is an example of a test.jxu file listing several hypothetical JXGeneric programs:
<jxu>
<generic name="CreateUser" config=”user.xml”/>
<generic name="CreateUserAccount" config="userAccount.xml" />
<generic name="TestAccountCalculation" config="accountTransactions.xml" />
<generic name=”RemoveUserAccount” config=”userAccount.xml” />
<generic name="RemoveUser" config="user.xml" />
</jxu>
The above configuration is hypothetical and could be implemented many different ways, but it illustrates how a test could be configured. In the above example, the first JXGeneric test is responsible for creating a system user. The second test creates the users account. The TestAccountCalculation class is the primary test run in this configuration. It’s responsible to verify that the account calculations for the system are correct for the given configuration (i.e. accountTransactions.xml). The remaining tests, RemoveUserAccount and RemoveUser are responsible for cleaning up the executed test. These cleanup tests could be combined with the CreateUser and CreateUserAccount with their respective configuration files defining the action (create or cleanup) that should take place in the test.
What makes this framework so useful is that you no longer need to code all the setup procedures in your individual JUnit tests. The setup procedures can now be specified as individual steps in you test.jxu file. And these procedures can be used over and over again. The framework also makes it possible for a developer to run the complete set of tests without knowing the details of each test. A directory structure of tests can be created and shared with each developer. This makes it easier to find defects early in the development cycle.