Most Workday Studio integrations have no automated tests. Teams develop assemblies, deploy them to a sandbox tenant, run them manually, and verify the output by eye. When something breaks — after a Workday release, a schema change, or an edit to the XSLT — they find out in production.

This is not a tooling gap. Studio ships with AUnit, a built-in unit-testing framework based on JUnit 3. AUnit lets you test individual assembly components — transformations, mediation logic, routing decisions — locally, without deploying to a tenant. The framework has been available for years, but adoption remains low, partly because documentation is scarce and partly because the testing habit never took root in most Workday integration teams.

This guide walks through writing your first AUnit test, from setup to execution.

What AUnit Tests

AUnit operates at the assembly component level. You can test:

  • XSLT transformations: supply an input XML document, run the transformation, and assert properties of the output.
  • MVEL expressions: evaluate an expression against a known input and verify the result.
  • Mediation logic: test how a mediation step modifies, filters, or routes a message.
  • Routing decisions: verify that a Choice Router sends messages down the correct branch for given inputs.
  • Subassemblies: test a reusable assembly fragment in isolation.

AUnit does not test transport-level behavior (SFTP connections, HTTP calls to external APIs) or tenant-specific configuration (business process triggers, security group permissions). Those require integration-level testing against a live tenant. AUnit covers the logic inside the assembly — the parts most likely to break when data or schemas change.

Setting Up Your First Test

AUnit tests live inside the same Studio project as the integration they test. To create one:

  1. Right-click your Studio project in the Package Explorer and select New > AUnit Test Case. Studio creates a Java class that extends the AUnit test base class (built on JUnit 3's TestCase).

  2. Name the test class after the component it tests. If you are testing a transformation called MapWorkerToPayroll.xsl, name the test MapWorkerToPayrollTest. Convention matters — when you have dozens of tests later, naming tells you instantly what broke.

  3. Create test data. AUnit tests need input data — typically XML documents that represent the messages your assembly components process. Create a testdata/ directory in your project and add sample XML files. These should be realistic but small: enough to exercise the logic, not a full production payload.

For transformations, you need both the input XML and the expected output XML. For routing tests, you need input documents that should trigger each branch of the router.

Anatomy of a Test Case

An AUnit test case follows the standard JUnit 3 pattern: a class with test* methods, each method exercising one scenario.

A typical transformation test:

  1. Load the input. Read the test XML from your testdata/ directory into a message object.
  2. Run the component. Execute the XSLT transformation (or MVEL expression, or mediation step) against the input message.
  3. Assert the output. Check that the resulting message contains the expected elements, values, and structure.

Assertions can check:

  • Element existence: does the output contain a specific XML element?
  • Element values: does a particular field contain the expected value after transformation?
  • Element count: did a Splitter produce the expected number of output messages?
  • Structure: does the output conform to the expected schema?

Keep each test method focused on one behavior. A test called testEmptyWorkerIDReturnsDefault is more useful when it fails than one called testTransformation.

Running Tests

AUnit tests run locally in Studio — no tenant connection required. Right-click the test class (or the project) and select Run As > AUnit Test. Studio executes the tests using its local runtime and displays results in the JUnit view:

  • Green bar: all tests passed.
  • Red bar: at least one test failed. Click the failed test to see the assertion failure message and stack trace.

Tests run in seconds because they execute locally without network calls or tenant interaction. This fast feedback loop is the main advantage over the deploy-and-check cycle.

What to Test First

If your integration has no tests today, start with the highest-risk component — usually the main XSLT transformation. This is the part most likely to break after a Workday release changes the XML schema, and it is the most time-consuming to debug manually.

Write three tests for it:

  1. The expected case. A well-formed input that represents normal data. Verify the output structure and key field values.
  2. An edge case. Input with missing optional fields, empty elements, or boundary values (zero amounts, long strings, special characters). These are the cases that produce silent data corruption rather than outright failures.
  3. A schema-change scenario. Input that simulates what happens when Workday adds, removes, or renames an element. This test will catch namespace mismatches and template-match failures early — before they reach production during a Workday release weekend.

Three tests for one component is a starting point, not a finish line. But three tests that run on every build catch more regressions than zero tests reviewed manually.

Building the Testing Habit

The challenge with AUnit adoption is not the framework — it is the habit. Integration teams are often under deadline pressure, and writing tests for an integration that "already works" feels like overhead.

Two practices help:

Test before you fix. When a production integration fails and you identify the root cause, write an AUnit test that reproduces the failure before you apply the fix. Run the test to confirm it fails, then fix the code, then run the test again to confirm it passes. This ensures the same failure cannot recur silently, and it adds to your test suite without dedicated "testing time."

Test after you inherit. When you take over an integration built by someone else — a common scenario in Workday teams — the first thing to do is write AUnit tests for its critical transformations. You do not need to understand the entire assembly to test one XSLT. The tests document what the integration actually does, which is more reliable than whatever documentation (if any) was left behind.

Scaling Beyond Manual Tests

As your test suite grows, the constraint shifts from writing tests to managing test data and keeping assertions current. This is where tooling helps.

kiweely's Studio plugin can generate AUnit tests from an integration's existing assembly — it reads the XSLT, creates input XML fixtures, writes the test class, and runs it through Studio's AUnit framework. When a Workday release changes the XML schema, kiweely can update both the transformation and its tests in one pass, then run the suite to verify nothing else broke.

Whether you write tests by hand or generate them with tooling, the principle is the same: an integration with automated tests is one you can change with confidence. An integration without them is one you change with anxiety. Start with one transformation and three test cases. The habit builds from there.

Sources checked