How to run Creo Elements/Direct Model Manager unit tests

Creo Elements/Direct Model Manager Customization Guide > Java Extension > Extension development environment > How to run Creo Elements/Direct Model Manager unit tests

Unit tests test individual software components, such as a single Java class. The Creo Elements/Direct Model Manager unit test suite is included with the Creo Elements/Direct Model Manager source code. You can run the unit tests from the NetBeans extension development environment. The Creo Elements/Direct Model Manager unit tests use the junit test framework, an open source unit test infrastructure available at http://www.junit.org.

You should run the Creo Elements/Direct Model Manager unit tests while developing and testing your extension to ensure that your extension does not break base Creo Elements/Direct Model Manager functionality. You can also add unit tests for your extension.

The Creo Elements/Direct Model Manager unit tests are run from the NetBeans development environment. You must have Creo Elements/Direct Drafting installed to run some of the tests.

You need to run unit tests against a test database with the medmgr login, having the password "medmgr".

Running the test suite

To run the unit tests,

1. In the dev.properties file, set run.mode to UnitTests.

2. You can either run the Creo Elements/Direct Model Manager unit tests and the custom unit tests, or only the custom unit tests (the default). To run the unit tests along with custom unit tests, change the value of run.mm.tests to true.

3. Execute the run script (dev_tools\run.xml). The tests will take 30 to 60 minutes, depending on the speed of your computer and the number of tests run.

• Unit test execution messages will appear in the Output tab at the bottom of the NetBeans window.

• When the tests are complete a Web page (unit_tests.log-summary.html) showing test results will be displayed. The links of packages that had test failures are displayed with a pink background. The log files are overwritten each time the unit tests are run. The following test log files are created in your playpen (usually \users\custom).

• unit_tests.log

• unit_tests.log.html

• unit_tests.log-summary.html

To stop the unit tests, execute the stop.unit.tests script from NetBeans.

Running the unit test suite adds data to the database. Do not run the unit tests against a production database.

Running an individual unit test

There are two ways to run an individual unit test:

1. Select the test class in the directory structure and execute it. The test will run if the test class has a main() method.

2. Specify the tests to be run in the start_unit_tests target of the run.xml. List the test classes as arguments to the java task. For example, add:

See Specific test idiosyncrasies if you have problems with specific tests.

Disabling tests

When you change the functionality of the product, you should expect some of the tests to fail. Once you understand the test failures, you can disable those specific tests.

Disable specific tests or groups of tests by listing them in a test exclusion file called dont_run.txt at the top of your playpen (\users\custom in the examples in this document).

Use the asterisk (*) wildcard to exclude a group of tests.

Each line of the file disables one or more tests. For example,

• com.osm.datamgmt.biz.PartTest.testEditLinkAttributes prevents just the test method testEditLinkAttributes in PartTest from being executed. All of its other methods will be executed.

• com.osm.ui.taskbar.MainTaskBarTest turns off just the MainTaskBarTest.

• com.osm.ui.* turns off all of the tests under com.osm.ui.

When unit tests are run any classes that are excluded will have *** TURNED OFF IN dont_run.txt*** displayed after their class name/method in the run tab at the bottom of the NetBeans window and in the log files.

Adding tests

You can add tests to test your extension. If your test class follows the these conventions, it will be seen and run by the test framework:

• The test's Java class must extend junit.framework.testcase somewhere in its class hierarchy.

• The name of the file must end with "Test".

Writing tests

Writing good unit tests is an art and a skill. The Creo Elements/Direct Model Manager development team has adopted the following best practices for creating useful and robust unit tests:

• Extend test.com.osm.WMTestCase. This class provides many utilities for developing tests.

• Describe the functionality being tested in the classname, and append that with "Test". For example, ActionMenuTest or LoadRuleTest. This naming convention must be followed for the test driver to find the unit test class.

• Include a main() in the test class so you can run the test outside of the test suite. You can then run the test and watch what it is doing to understand a test failure.

• Unit tests should be in the same package as the object they are testing so that they have access to package protected methods and fields. NetBeans supports this with the src directory for tested objects and the test directory for test objects. Tests are in the same package (com.osm.biz) as the tested objects, but stored in a different directory (test\com\osm\biz) than the tested objects (src\com\osm\biz).

Ordering tests

It is best to write unit tests that can be run independently, in any order. If you must write tests that depend on order, you can create a UnitTests class for the tests in a directory. If a directory has a UnitTests class, only the UnitTests class will be run. It is responsible for running each of the tests in the required order.

Specific test idiosyncrasies

MyPacketListTest

If the MyPacketListTest fails and you want to run the test manually in NetBeans, you must set the MEDIR environment variable to the full path name of the Creo Elements/Direct Manager Server macros directory (usually C:\Program Files\PTC\Creo Elements\Direct Manager Server 20.6\macros) before you start NetBeans. If you do not set MEDIR you will get an "Invalid input" error.

The MEDIR variable affects other Creo Elements/Direct Manager Server applications. Record the existing value of the variable before changing it. After you finish running the test, return the MEDIR variable to its previous value, or unset it if it was not previously set.

Was this helpful?