Files
everything-claude-code/skills/tinystruct-patterns/references/testing.md
James M. ZHOU f01929c31a feat: add tinystruct-patterns skill and bootstrapping guidance (#1336)
* feat: add tinystruct-patterns skill and bootstrapping guidance

* docs(skills): restructuralize tinystruct-patterns to standard skill format

- Reorganize SKILL.md and all reference documents into "When to Use", "How It Works", and "Examples" sections to conform to project standards.
- Refine data-handling.md example to return Builder objects directly, leveraging framework auto-serialization.
- Simplify @Action examples in routing.md for better readability.
- Clarify framework mechanics including CLI bootstrapping via ApplicationManager.init(), event-driven architecture, and regex-based routing.

* Update skills/tinystruct-patterns/references/testing.md

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

* Update skills/tinystruct-patterns/SKILL.md

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

* Update skills/tinystruct-patterns/references/routing.md

Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>

* Update skills/tinystruct-patterns/references/testing.md

Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>

* Update skills/tinystruct-patterns/references/testing.md

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

---------

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
2026-05-11 01:19:44 -04:00

2.2 KiB

tinystruct Testing Patterns

When to Use

Use the testing patterns described here when writing units tests for your tinystruct applications with JUnit 5. These patterns are essential for verifying that your @Action methods return the correct results and that your routing logic is properly registered within the singleton ActionRegistry.

How It Works

Testing tinystruct applications requires a specific setup to ensure framework-level features like annotation processing and configuration management are active. By creating a new instance of your application and passing it a Settings object in the setUp() method, you trigger the init() lifecycle. This ensures all @Action methods are discovered and registered.

Because the ActionRegistry is a singleton, it is critical to maintain isolation between tests by properly initializing your application state before each test execution, preventing side effects from leaking across the test suite.

Examples

Unit Testing an Application

import org.junit.jupiter.api.*;
import org.tinystruct.application.ActionRegistry;
import org.tinystruct.system.Settings;

class MyAppTest {

    private MyApp app;

    @BeforeEach
    void setUp() {
        app = new MyApp();
        Settings config = new Settings();
        app.setConfiguration(config);
        app.init(); // triggers @Action annotation processing
    }
    void testHello() throws Exception {
        // Direct invocation via the application object
        Object result = app.invoke("hello");
        Assertions.assertEquals("Hello, tinystruct!", result);
    }

    @Test
    void testGreet() throws Exception {
        // Invocation with arguments
        Object result = app.invoke("greet", new Object[]{"James"});
        Assertions.assertEquals("Hello, James!", result);
    }
}

Testing via ActionRegistry

If you need to test the routing logic itself, use the ActionRegistry singleton to verify path matching:

@Test
void testRouting() {
    ActionRegistry registry = ActionRegistry.getInstance();
    // Verify a path matches an action
    Action action = registry.getAction("greet/James");
    Assertions.assertNotNull(action);
}

Reference: src/test/java/org/tinystruct/application/ActionRegistryTest.java