BWUnitUser GuideVersion 1.5

Contents

Introduction

This document will guide you through:

Resources

The BWUnit homepage can be found at http://windyroad.org/software/bwunit/ . Community discussion forums for BWUnit can be found at http://windyroad.org/discussion/ and the Windy Road team is looking forward answer your support questions at http://windyroad.org/support/ .

Related Software

BWUnit and it's example projects rely on the following software:

TIBant

TIBant provides a set of Apache Ant macros for building and deploying TIBCO Business Works projects.

More information about TIBant can be found at http://windyroad.org/software/opensource/tibant/ and documentation for TIBant can be found at http://windyroad.assembla.com/spaces/tibant/documents/ac_SBEqkOr4kwJeJe5cbCb/download

Apache Ant

Apache Ant is a software tool for automating software build processes. Ant uses XML to describe the build process and its dependencies. More information about Apache Ant can be found at http://en.wikipedia.org/wiki/Apache_Ant and documentation for Apache Ant can be found at http://ant.apache.org/manual/index.html

Apache Ant is a recommended requirement when using BWUnit, though the core functionality of BWUnit can be used without Apache Ant. In order to use the provided Apache Ant macros (including those for Unit Test Report generation) and to use the Apache Ant build scripts of the provided examples, Apache Ant 1.7.0 or later is required.

H2

H2 is a fast, light-weight Java SQL database. It's ability to run as an in-memory database make it ideal for unit testing.

More information about H2 can be found at http://www.h2database.com/html/main.html and the documentation for H2 can be found at http://www.h2database.com/html/quickstart.html

Apache ActiveMQ

Apache ActiveMQ is an open source implementation of the supporting JMS 1.1 standard. It's support for running as an in-memory (A.K.A. embedded) JMS Server make it ideal for unit testing.

More information about Apache ActiveMQ can be found at http://activemq.apache.org/ and the documentation for Apache ActiveMQ can be found at http://activemq.apache.org/getting-started.html

Conventions

The following conventions are used within this user guide:

Formatting Description
code Code fragments and command line examples are represented using this formatting.
${bwunit.home} Is used to represent the install location of BWUnit. e.g., C:\Program Files\Windy Road\BWUnit-1.3.0
${tibco.home} Is used to represent the base TIBCO installation path. e.g., C:\tibco
${user.home} Is used to represent your home directory. e.g., C:\Users\John Doe
${user.name} Is used to represent the login name of the current user. e.g., John Doe

© Windy Road Technology Pty. Limited 2009-2011. All Rights Reserverd.

This product contains icons from http://famfamfam.com/lab/icons/silk/, which are licensed under the Creative Commons Attribution 3.0 License

Installation

System Requirements

To use BWUnit, the following software and their dependencies are required:

Name Version
TIBCO Business Works 5.3 or later
Firefox 3.5.8 or later

Optional Requirements

Name Version Notes
Apache Ant 1.7.0 or later Required for automated test execution scripts
TIBCO Designer 5.6 or later BWUnit can be used with versions of TIBCO Designer that ship with BW 5.3 onwards, however the Complex example requires TIBCO Designer 5.6 or later, which provides the buildlibrary executable for building Design Time Libraries from the command line.

Installation Steps

Unpacking

Installing Your BWUnit License

BWUnit requires a valid license in order to operate. If you do not already have a license, please request one from http://windyroad.org/software/bwunit/licensing/

License Installation via the UI

When BWUnit is run interactively, if a license is not detected or if the license has expired, it will prompt you for your license. When prompted for your license:

License Installation via Ant

When BWUnit is run via Apache Ant, the test run will fail if a license is not installed or if the license has expired. To allow license installation in situations where it is not possible or convenient to run BWUnit interactively, the bwunit:run-tests macro accepts a license attribute, which can be used the specify the license to use during the test run.

To install your license via Ant, first follow the steps below in the Integrating BWUnit with Your Project section to configure your Apache Ant build file, then prior to the bwunit:run-tests call, load your license file into a property. e.g.,

<loadfile srcFile="path/to/license.b64.txt" property="my.bwunit.license">

Add a license attribute to your bwunit:run-tests call, set to the value of the property the license was loaded into. e.g.,

<bwunit:run-tests dir="src/bw"
    project="Simple"
    result-dest-dir="build/test-reports"
    license="${my.bwunit.license}"/>

Using the Example Projects

Configuring the Example Projects

The example projects use a set of default paths to various TIBCO components. These defaults can be found in the beginning of ${bwunit.home}/lib/tibant/tibant.xml and are currently set to

tibco.home=c:/tibco
tibco.home.jre=${tibco.home}/jre/1.5.0
tibco.home.bw=${tibco.home}/bw/5.8
tibco.home.designer=${tibco.home}/designer/5.6
tibco.home.tra=${tibco.home}/tra/5.6
tibco.home.tpcl=${tibco.home}/tpcl/5.6
tibco.home.hawk=${tibco.home}/hawk
tibco.home.rv=${tibco.home}/tibrv/8.1

You can override these defaults by creating your own properties file with your own paths in either of the following locations:

Executing the Examples Tests Interactively

Executing the Self Test Example interactively

The self test example contains a number of BWUnit unit tests that test BWUnit itself.

Executing the Simple Example Interactively

The Simple BWUnit example demonstrates how BWUnit can be used to test a BusinessWorks project. A H2 in-memory database is used to replace the need to unit test using a production like database and to ensure the tests are repeatable. Similarly, Apache ActiveMQ is used to provide an in memory (A.K.A. embedded) JMS implementation, rather than requiring a JMS server for unit testing purposes.

To run the tests:

Executing the Complex Example Interactively

The Complex BWUnit example uses a design time library to encapsulate calls to a database. For unit testing purposes, a mock design time library is used to replace the database calls.

Executing the Example Tests Non-interactively

To run the example tests non-interactively, run the test Ant target for either the Self Test, Simple of Complex example. e.g.,

cd ${bwunit.home}/Examples/Simple
ant test

The results will appear in the BWUnit/Examples/*/build/test-reports folder.

Unit Testing with BWUnit

Integrating BWUnit with Your Project

Apache Ant is the preferred mechanism for integrating BWUnit with your project. However, as mentioned in the requirements section above, Apache Ant is not required for you to use the core BWUnit functionality. Please refer to the end of this section for details on how to configure your project to use BWUnit without Apache Ant.

The Apace Ant macros provided allow you to configure the class path and files aliases for you project within your build script, which can then be used to both launch TIBCO Designer or run your TIBCO Business Works project (in order to execute its BWUnit tests). However, the main benefit of configuring your project's class path and files aliases from within an Apache Ant build script, is that the configuration can then be easily shared between developers and stored in version control.

Configuring your project to use Apache Ant is out of the scope of this document and the steps below assume your project already has a Apache Ant build script. If your project does not currently use Apache Ant, you might find the build.xml provided within the example SelfTest project to be a good starting point for your project.

Within your Apache Ant build.xml(You can place your build.xml anywhere within your project, however we recommend placement in the root directory as per recommendation #2 at http://onjava.com/pub/a/onjava/2003/12/17/ant_bestpractices.html):

  1. Set the bwunit.home property to the location your BWUnit installation. e.g.,:
    <property name="bwunit.home" value="C:/Program Files/Windy Road/BWUnit-1.3.0"/>
    
  2. The provided Apache Ant scripts expect specific versions of the TIBCO products to be installed in their default locations. You can override these defaults by setting the following properties(Supporting different development environment configurations can be difficult for any project. We support and use the recommendations made at http://www.javaranch.com/ant/properties.jsp. You can see this in action in the provided Example projects.):
    <property name="tibco.home" value="c:/tibco"/>
    <property name="tibco.home.jre" value="${tibco.home}/jre/1.5.0"/>
    <property name="tibco.home.bw" value="${tibco.home}/bw/5.8"/>
    <property name="tibco.home.designer" value="${tibco.home}/designer/5.6"/>
    <property name="tibco.home.tra" value="${tibco.home}/tra/5.6"/>
    <property name="tibco.home.tpcl" value="${tibco.home}/tpcl/5.6"/>
    
  3. Add the following import directive:
    <import file="${bwunit.home}/util/bwunit.xml"/>
    
  4. Specify a namespace prefix for the BWUnit and TIBant macros, by adding xmlns:tibant="org.windyroad.tibant" and xmlns:bwunit="org.windyroad.bwunit" to the root project element in your build file. For example
    <project default="build" 
             name="MyProject" 
             xmlns:tibant="org.windyroad.tibant" 
             xmlns:bwunit="org.windyroad.bwunit">
    
  5. BWUnit and TIBant uses a number of Ant tasks provided by the ant-contrib library. If you do not already load ant-contrib in your build file, then you also need to add the following line after your BWUnit import call. This can be added either at the top level or within a target, so long as it get's called before any of the BWUnit or other TIBant macros.
    <tibant:load-ant-contrib/>
    
  6. Create a target to execute your BWUnit tests. e.g.,:
    <target name="test" description="execute BWUnit Tests">
    </target>
    
  7. Within the target:
    • Create properties for the file aliases required by your project e.g.,:
      <property name="myproject.alias.some-lib.jar" file="some-path/some-lib.jar"/>
      <property name="myproject.alias.some-dtl.projlib" file="some-path/some-dtl.projlib"/>
      
    • Add those properties to a propertyset. e.g.,:
      <propertyset id="myproject.aliases">
          <propertyref prefix="myproject.alias." />
          <mapper type="glob" from="myproject.alias.*" to="*"/>
      </propertyset>
      
    • Add the bwunit:run-tests macro, with the dir attribute set to the directory containing your Business Works project, the project name of the Business Works project within that directory, the result-dest-dir attribute to the directory where you want the test reports saved and aliases-refid set to the id of your aliases propertyset. e.g.,:
      <bwunit:run-tests dir="src/bw" 
                        project="MyProject"
                        result-dest-dir="build/test-reports" 
                        aliases-refid="myproject.aliases"/>
      
      • The bwunit:run-tests macro is designed to track dependencies and only re-execute the tests if one of those dependencies has changed. If desired, you can force it to run the tests every time, by setting the force attribute to true. e.g.,:
        <bwunit:run-tests dir="src/bw" 
                          project="MyProject"
                          result-dest-dir="build/test-reports"
                          aliases-refid="myproject.aliases"
                          force="true"/>
        
  8. Create a target to launch designer. e.g.,:
    <target name="designer" description="Launch Project in TIBCO Designer">
    </target>
    
  9. Within the target:
    • Create properties for the file aliases required by your project e.g.,:
      <property name="myproject.alias.some-lib.jar" file="some-path/some-lib.jar"/>
      <property name="myproject.alias.some-dtl.projlib" file="some-path/some-dtl.projlib"/>
      
    • Add those properties to a propertyset. e.g.,:
      <propertyset id="myproject.aliases">
          <propertyref prefix="myproject.alias." />
          <mapper type="glob" from="myproject.alias.*" to="*"/>
      </propertyset>
      
    • Add the tibant:designer macro, with the dir attribute set to the directory containing your Business Works project, the project name of the Business Works project within that directory, the aliases-refid set to the id of your aliases propertyset and create-dtl-file set to true. e.g.,:
      <tibant:designer dir="src/bw"
                       project="MyProject"
                       aliases-refid="myproject.aliases"
                       create-dtl-file="true" />
      
  10. Optionally, you can create a script to launch your project in designer from your windowing environment. This allows you to maintain the advantages of using the Ant to manage your file aliases and class paths, while still being able to launch designer with a double click. To do this, simply create a Windows BAT file or Unix shell script in your projects root directory, which calls the designer target you have created. For instance for Windows:
    ant designer
    or for Unix
    #!/bin/sh
    cd `dirname $0`
    ant designer

Your project is now configured to use BWUnit. Please see the 'Executing the Simple Example interactively' and the 'Executing the Simple Example Test Non-interactively' sections for how to execute BWUnit tests within your project.

Setting Engine Properties from Ant

BW engine properties to be used when the bwunit:run-tests macro is run can be set from within Ant by creating a propertyset and passing the refid into the bwunit:run-tests macro via the properties-refid attribute. For instance to enable job statistics, use:

<property name="myproject.property.bw.engine.jobstats.enable" value="true"/>
<propertyset id="myproject.properties">
    <propertyref prefix="myproject.property." />
    <mapper type="glob" from="myproject.property.*" to="*"/>
</propertyset>

and then

<bwunit:run-tests dir="src/bw" 
                  project="MyProject"
                  result-dest-dir="build/test-reports"
                  properties-refid="myproject.properties"/>

Setting Global Variables from Ant

Global Variables to be used when the bwunit:run-tests macro is run, can be set from within Ant by creating a propertyset and passing the refid into the bwunit:run-tests macro via the global-variables-refid attribute. For instance to change the port the BWUnit service uses to 6767, use:

<property name="myproject.globalvars.BWUnit/HTTP-service-port"
          value="6767"/>
<propertyset id="myproject.globalvars">
    <propertyref prefix="myproject.globalvars." />
    <mapper type="glob" from="myproject.globalvars.*" to="*"/>
</propertyset>

and then

<bwunit:run-tests dir="src/bw"
                  project="MyProject"
                  result-dest-dir="build/test-reports"
                  global-variables-refid="myproject.globalvars"/>

Setting File Aliases from Ant

File Aliases to be used when the bwunit:run-tests macro is run, can be set from within Ant by creating a propertyset and passing the refid into the bwunit:run-tests macro via the aliases-refid attribute. For instance to add myproject.jar as a file alias, use:

<property name="myproject.aliases.myproject.jar" value="some-path/myproject.jar"/>
<propertyset id="myproject.aliases">
    <propertyref prefix="myproject.aliases." />
    <mapper type="glob" from="myproject.aliases.*" to="*"/>
</propertyset>

and then

<bwunit:run-tests dir="src/bw"
                  project="MyProject"
                  result-dest-dir="build/test-reports"
                  aliases-refid="myproject.aliases"/>

Controlling the Class Path from Ant

If your project requires additional jar files or directories in the class path, you can manually set the class path using the custom-cp-ext-prepend and custom-cp-ext-append attributes. e.g.,

<bwunit:run-tests dir="src/bw"
                  project="MyProject"
                  result-dest-dir="build/test-reports" 
                  custom-cp-ext-prepend="g:/a1/b1;d:/a2/b2/c.jar"/>

Manually Configuring Designer to use BWUnit

In situations where you do not want to launch Designer from Ant, you may configure your project to use BWUnit by creating the following File Aliases:

Alias Location
BWUnit.jar ${bwunit.home}/BWUnit.jar
BWUnit.projlib ${bwunit.home}/BWUnit.projlib
commons-codec-1.3.jar${tibco.home}/tpcl/_<VERSION>_/lib/commons-codec-1.3.jar

Then open the project in TIBCO Designer and:

Creating Tests and A Testing Hierarchy

BWUnit Tests are arranged in a hierarchy, comprised of folders. Test Suites can contain Test Cases and other Test Suites. Test Cases can contain Tests and optionally a Fixture.

Example Testing Hierarchy
Example Testing Hierarchy

Creating Test Suites

Test Suites represent a collection of Test Cases. To create a Test Suite, create a folder ending with TestSuite.

Creating Test Cases

Test Cases represent a collection of Tests that shared a common Fixture. To create a Test Case, create a folder within a Test Suite ending with TestCase.

Creating Tests

Tests contain the logic that verifies if your processes behave in the manner they are expected to. They provide a mechanism for encoding the requirements for the processes they test.

To create a Test:

  1. Copy the BWUnit/Public/Templates/Test.process into a Test Case.
  2. Rename the copy. Any name except Fixture is permitted.
  3. Modify it to call a process (or processes) you want to test.
  4. Enter specific input to the process (or processes).
  5. Add Asserts to check the output generated is what it is expected.

Test Examples

Example of a Simple Test
Example of a Simple Test

In the example above, a Call Process activity is used to link a specific customer to an account. Another Call Process activity is then used to retrieve the accounts linked to that customer. An Assert Equals is then used to check the the customer is linked to the correct number of accounts.

Example of a More Complex Test
Example of a More Complex Test

The example above is a unit test for AssertDoesNotEqual. Each instance of AssertDoesNotEqual is provided with a different input, to test different boundary conditions. When an error is expected, there is a success transition to an AssertFail and an error transition to an AssertEquals, which checks that the error generated matches the error we expect.

Creating Fixtures

Fixtures provide a mechanism for preparing (and cleaning up) the necessary state to run a particular test and expect a particular outcome. For instance, a fixture may create some records in an in-memory database, which the process being tested will query against.

To create a Fixture:

  1. copy BWUnit/Public/Templates/Fixture.process into a Test Case
  2. Add Activities to setup the required state in between the Start and the runWrappedTest activities.
  3. Add Activities to perform any required clean up after the test is run, in between the runWrappedTest and end activities.
Fixture Examples
Example of a Simple Fixture
Example of a Simple Fixture

In the example fixture above, a Call Process activity is used to spawn a stub, which will wait for a message, which will be sent by the test.

Example of a More Complex Fixture
Example of a More Complex Fixture

In the example fixture above, a transaction group is used with a generate error activity to rollback the database changes made by the Prep Data activity any changes that are made by the test. This ensures that each test within the test case this fixture belongs to, has the exact same data within the database for every single test run.

Adding Asserts to Tests

Asserts are used to confirm that the output of a call to a particular process is what is expected.

To add an assert to your test:

  1. Drag the desired assert from the Project pane to your process
  2. Create a transition to the assert from the desired activity
  3. Set the desired input on the Assert
  4. Create a transition from the Assert to the next desired Activity.

Generating Unit Test Reports

BWUnit generates Unit Test reports via the supplied bwunit-run-tests Apache Ant macro. As described in the Configuring Your Project to Use BWUnit section, the result-dest-dir attribute is used to specify the directory you want BWUnit to create the reports in. e.g., to generate the reports in build/test-reports, set the result-dest-dir attribute as follows:

<bwunit-run-tests project="${basedir}/src/bw/MyProject"
                  result-dest-dir="build/test-reports"/>

The bwunit-run-tests Apache Ant macro creates the following files in the specified directory:

Name Description Purpose
results.status Contains the HTTP status code from calling the BWUnit runAllTestSuites Web Service operation. This file is used primarily for debugging purposes.
results.soap Contains the SOAP message returned from calling the BWUnit runAllTestSuites Web Service operation.This file is used for debugging purposes and to generate results.xml
results.xml Contains the BWUnit test report in a BWUnit specific XML format. This file is used as a record of the test results and as a basis for transformation into other formats.
Example HTML BWUnit Test Report
Example HTML BWUnit Test Report

Continuous Integration

BWUnit is designed to work with your Continuous Integration server, such as Hudson/Jenkins, CruiseControl or ThoughtWorks Go. The provided bwunit-run-tests Apache Ant macro produces NUnit compatible XML output, allowing your Continuous Integration server to clearly indicate which test(s) failed and why.

Simply configure your Continuous Integration server to call your test target and specify that the NUnit test results is named results-nuf.xml within the specified result-dest-dir.

For example, to have Hudson run the tests in the Simple Example that comes with BWUnit, the relevant settings are:

Section Field Value
Build Targets test
Post-build Actions Publish NUnit test result report checked
Post-build Actions Test report XMLs build/test-reports/results-nuf.xml
Hudson Dashboard for the BWUnit Project
Hudson Dashboard for the BWUnit Project

BWUnit Service Operations and Public Processes

BWUnit provides a number of public processes that may be called directly from the Designer Tester or from your own code, either via a Call Process activity or via it's corresponding operation in the BWUnit service.

License Management

The following processes provide methods for managing BWUnit licenses.

Process installLicense.process
Full Path /BWUnit/Public/Processes/installLicense.process
Corresponding Operation installLicense
Description Installs the provided binary BWUnit license key
On Success License is installed. License details are returned.
On Error License is not installed. Exception is thrown with error details.
Process uninstallLicense.process
Full Path /BWUnit/Public/Processes/uninstallLicense.process
Corresponding Operation uninstallLicense
Description Uninstalls the currently installed BWUnit license.
On Success License is uninstalled.
On Error N/A
Process verifyLicense.process
Full Path /BWUnit/Public/Processes/verifyLicense.process
Corresponding Operation verifyLicense
Description Checks the validity of the currently installed BWUnit license.
On Success License is valid. License details are returned.
On Error License is not valid or not installed. Exception is thrown with error details.

Test Introspection

The following process allows for test introspection.

Process getTestSuites.process
Full Path /BWUnit/Public/Processes/getTestSuites.process
Corresponding Operation verifyLicense
Description Returns a hierarchy of Tests within the engine as per the specified settings.
On Success Test hierarchy is returned.
On Error Exception is thrown with error details.

Test Execution

The following processes provide methods for executing tests.

Note: Exceptions within a tests or fixtures are not propagated up through these processes. Exceptions within tests or fixtures are captured and their details are provided within a testfailure element within the test results.

Process runAllTestSuites.process
Full Path /BWUnit/Public/Processes/runAllTestSuites.process
Corresponding Operation runAllTestSuites
Description Executes all tests found within the engine as per the specified settings.
On Success Test results are returned.
On Error Exception is thrown with error details.
Process runTestSuite.process
Full Path /BWUnit/Public/Processes/runTestSuite.process
Corresponding Operation runTestSuite
Description Executes all tests within the test suite specified, found within the engine as per the specified settings.
On Success Test results for the specified suite are returned.
On Error Exception is thrown with error details.
Process runTestCase.process
Full Path /BWUnit/Public/Processes/runTestCase.process
Corresponding Operation runTestCase
Description Executes all tests within the test case specified, found within the engine as per the specified settings.
On Success Test results for the specified case are returned.
On Error Exception is thrown with error details.
Process runTest.process
Full Path /BWUnit/Public/Processes/runTest.process
Corresponding Operation runTest
Description Description Executes the test specified, found within the engine as per the specified settings.
On Success Test result for the specified test is returned.
On Error Exception is thrown with error details.

Engine Control

The following process may be used to shutdown the test engine.

Process stopEngine.process
Full Path /BWUnit/Public/Processes/stopEngine.process
Corresponding Operation runTest
Description Stops the Business Works engine. NOTE: When executed within the TIBCO Designer tester, it will shutdown TIBCO Designer.
On Success Engine is shutdown
On Error Exception is thrown with error details.

Extending BWUnit

BWUnit can be extended either by providing your own test execution interface or by providing custom asserts.

Custom Test Execution Interface

A Custom Test Execution Interface can be created by developing custom code to call the BWUnit Web Service operations and Public Processes documented above. For instance, to create a Test Execution interface within Parasoft® SOATest™, create a SOATest test that executes the runAllTestSuites operation and asserts that no test-failure elements exist in the returned test-suites-results.

Custom Asserts

Custom Asserts can be created by developing new processes as follows:

Process Input The input to an custom assert should extend the input-type complex type in the BWUnit-Asserts schema.
Process Output A custom assert should have no output.
Process Error The error generated when the custom assert fails should extend the assertion-error-type in the BWUnit-Errors schema. The message element should be set to the msg element passed to the custom assert. The messageCode element should be unique for that assert. The assertion element should be the full path to the assertion. e.g., BWUnit/Public/Asserts/AssertEqual.process

Further Reading

xUnit Test Patterns

The xUnit Test Patterns book and website provide many unit testing patterns and approaches, along with anti-patterns or "smells". We highly recommend them to anyone who is serious about unit testing. The website can be found at http://xunitpatterns.com/

Apache Ant Macros

The following section details each of the Apache Ant macros provided by BWUnit

convert-to-html-results

Attributes

Parameters specified as attributes.

NameDescriptionRequiredDefault
file

The BWUnit Results file to convert.

Yesn/a
tofile

The file to write the JUnit formated results to.

Yesn/a

convert-to-junit-results

Converts the specified BWUnit results file into JUnit format

Attributes

Parameters specified as attributes.

NameDescriptionRequiredDefault
file

The BWUnit Results file to convert.

Yesn/a
tofile

The file to write the JUnit formated results to.

Yesn/a
hostname

The hostname to insert into the results.

No

localhost

convert-to-nunit-results

Converts the specified BWUnit results file into NUnit format

Attributes

Parameters specified as attributes.

NameDescriptionRequiredDefault
file

The BWUnit Results file to convert.

Yesn/a
tofile

The file to write the NUnit formated results to.

Yesn/a
project

Name of the project that was tested

Yesn/a

designer

Opens a project in TIBCO Designer, with BWUnit aliases

Attributes

Parameters specified as attributes.

NameDescriptionRequiredDefault
project

The name of the TIBCO Designer Project. e.g., MyProject

Yesn/a
dir

The directory the TIBCO Designer Project is in. e.g., src/bw

Yesn/a
aliases-refid

A propertyset refid for the file aliases needed by the project

No

empty-set

global-variables-refid

A propertyset refid for the Global Variables to set prior to launching designer. The specified Global Variables will have their values replaced within the projects defaultVars.substvar files and the original values will be lost. USE WITH CAUTION!

No

empty-set

working-dir

The working directory to launch TIBCO Designer from. e.g., build/working/@{project}

No

build/working/@{project}

create-dtl-file

If true, create the /.designtimelibs file in the project root directory, based on the aliases referenced by alaises-refid

No

true

heap-size

Specifies the initial Java heap size to allocate

No

256M

custom-path

this will be prepended to tibco.env.PATH

No

%EXISTING-VALUE%

custom-cp-ext

this will be prepended to tibco.class.path.extended

No

%EXISTING-VALUE%

custom-palette-path

this will be prepended to java.property.palettePath

No

%EXISTING-VALUE%

custom-lib-path

this will be prepended to tibco.env.LD_LIBRARY_PATH, tibco.env.SHLIB_PATH, tibco.env.LIBPATH

No

%EXISTING-VALUE%

application-args

Specifies the remaining command line arguments to pass into the application -d : to activate the debug info dump -help : to print a list of acceptable command line arguments

No
tasknameNo

bwunit:designer

install-license-local

Installs a BWUnit license locally

Attributes

Parameters specified as attributes.

NameDescriptionRequiredDefault
license

Your BWUnit license

Yesn/a

run-tests

Starts a Business Works engine locally and executes it's BWUnit tests. executes it's BWUnit tests. Planned Changes: In future versions of BWUnit, the html results will not be created automatically. Instead the html results will need to be created by an explicit call to the convert-to-html-results macro

Attributes

Parameters specified as attributes.

NameDescriptionRequiredDefault
project

The name of the TIBCO Designer Project. e.g., MyProject

Yesn/a
dir

The directory the TIBCO Designer Project is in. e.g., src/bw

Yesn/a
aliases-refid

A propertyset refid for the file aliases needed by the project

No

empty-set

global-variables-refid

A propertyset refid for the Global variables to use when running the project. See the configure-ear macro for details of the default Global Variables.

No

empty-set

properties-refid

A propertyset refid for the properties to use when executing the Business Works engine. For instance setting bw.engine.jobstats.enable to true will turn on Job Stats for the engine. See the configure-ear macro for details of the available engine properties.

No

empty-set

working-dir

The working directory. e.g., build/working/@{project}

No

build/working/@{project}

create-dtl-file

If true, create the /.designtimelibs file in the project root directory, based on the aliases referenced by aliases-refid

No

true

heap-size

Specifies the initial Java heap size to allocate

No

256M

custom-cp-ext-prepend

Customizable Classpath information. All classes and jars in these directories will be automatically picked up. You can also specify individual files. Use forward slashes only. e.g., g:/a1/b1;d:/a2/b2/c.jar

No

%EXISTING-VALUE%

custom-cp-ext-append

Customizable Classpath information. All classes and jars in these directories will be automatically picked up. You can also specify individual files. Use forward slashes only. e.g., g:/a1/b1;d:/a2/b2/c.jar

No

%EXISTING-VALUE%

application-args

Other arguments to application, JVM etc.

No
result-dest-dir

The directory to store the results. e.g., build/bwunit-results

No

build/bwunit-results

scope

The path within your BW Project to start looking for Test Suites.

No

/

suite-pattern

The regex pattern to use when searching for test suites. e.g., TestSuite$

No

TestSuite$

case-pattern

The regex pattern to use when searching for test cases e.g., TestCase$

No

TestCase$

fixture-pattern

The regex pattern to use when searching for fixtures e.g., ^Fixture$

No

^Fixture$

force

If true the tests will be re-executed. Otherwise the tests will only be re-executed if any of the dependancies are older than the previous results

No

false

failonerror

If true, fail the build if a test fails

No

false

license

If set, the provide license is installed prior to test execution. Otherwise the previoulsy install license will be used.

No
start-max-wait

The number of time units to wait for the BWEngine to start before executing the tests. If the BWUnit service port is not available after the specified number of time units, the test run will abort and the start-timeout-property will be set.

No

2

start-max-wait-unit

The unit of time to wait for the BWEngine to start before executing the tests. If the BWUnit service port is not available after the start-max-wait number of time units, the test run will abort and the start-timeout-property will be set.

No

minute

start-timeout-property

The property to set if the BWUnit port is not available after the specied wait period.

No

bwunit.start.timeout

stop-max-wait

The number of time units to wait for the BWEngine to stop after executing the tests. If the BWUnit service port in still available after the specified number of time units, the stop-timeout-property will be set.

No

60

stop-max-wait-unit

The unit of time to wait for the BWEngine to stop after executing the tests. If the BWUnit service port is still available after the stop-max-wait number of time units, the stop-timeout-property will be set.

No

second

stop-timeout-property

The property to set if the BWUnit port is still available after the specied wait period.

No

bwunit.stop.timeout

tasknameNo

bwunit:run-tests