Using Testing Executors

Several executors are supplied which make it easy to test API objects. The idea is that you can associate the executor with your, or anyone else's, object to test it, without adding test code (a main method) that would later need to be commented-out. You must have a public default constructor.

SystemAction Tester

This tester operates on SystemActions in three modes:

  1. On plain SystemActions, it calls the actionPerformed method (with a null argument). This is not likely to be useful for many people.
  2. On CallableSystemActions, it calls actionPerformed so you can test the action.
  3. On NodeActions (including subclasses like CookieActions), it first presents a selection dialog rooted at the Desktop. You must select a node (or combination of nodes) that the action accepts. When you press OK, the action will be run on those nodes. This lets you test both the performance of the action, and the correctness of the enablement logic.

This tester is the default executor for the Callable_action, Node_action and Cookie_action templates.

Presenter Tester

This tester lets you test the presenters of actions, so you can see how they will really appear--as well as test their enablement, and try running them.

Any action (or other object) tested by it must implement either Presenter.Menu or Presenter.Toolbar (or both). A frame will be displayed, possibly with a menu bar demonstrating the menu presenter, possibly with the toolbar presenter added to it. You can select the action via these means and make sure it works. You can also (e.g.) open an Explorer and start selecting some nodes, to check the enablement logic of (e.g.) a NodeAction.

This tester is the default executor for the Submenu_action and Grouping_action templates.

Executor Tester

This tester allows you to easily test new executors. Attach it as the executor for your own executor class. When you "run" your executor, you will be prompted for a "class" (or other object) in the Repository to pass to your executor (arguments set on that class will also be passed to your executor). First you are given the opportunity to customize the executor instance however you need.

You can also create customized versions of this tester that predefine the class name to test on, rather than prompting each time, which may be easier if you are testing it over and over again. If you predefine the class name, you may also predefine a list of arguments.

This tester is the default executor for the External_executor and Internal_executor templates.

CompilerType Tester

This tester allows you to test compiler types (usually associated with compiler and compiler group implementations). When set as the executor for a compiler type class, you will be prompted for an object in the Repository to pass to the compiler type. A new compiler job will be prepared and run according to your compiler type's behavior. First you are given the opportunity to customize the compiler type instance however you need.

The tester can be customized according to the style of compilation requested (compile, build, or clean); and according to the requested depth (files only, files and folders, or files and recursive subfolders).

This tester is the default executor for the External_compiler template.

Bean Tester

This tester just tries to instantiate the class it is run on as a JavaBean, then displays the result in the Bean Browser.

This tester is the default executor for the Leaf_node, Container_node, System_option, and Local_filesystem templates. But it can be used on any object with a public default constructor.

Testing JavaHelp

If you are using JavaHelp documentation, you can quickly take a peek at it in a real JavaHelp viewer. Just select a help set file and hit Execute.

Install JAR as Module

See below for a description of this tester, designed for live installation and testing of modules.