External Libraries & Test Cases

External Libraries are the container for extending ReAPI’s capabilities. They allow you to package custom code—including External Test Cases—and run it securely within the platform.

This approach bridges the gap between code-driven development and visual test management.

Why External Libraries?

The Web Editor: Great Start, Natural Limits

ReAPI’s web editor is perfect for getting started:

QA teams build tests visually without coding
Simple assertions and data generation work well
Quick iteration, immediate feedback

But as teams grow, limitations emerge:

Complex validation logic becomes hard to maintain
No IDE features (autocomplete, refactoring, debugging)
No version control or code review
Can’t use npm packages or external dependencies
Can’t unit test your test components

Teams Evolve

Most teams follow a natural progression:

Stage 1: QA-Only
├── QA builds all tests visually
├── Simple assertions, basic generators
└── Works great for straightforward APIs

Stage 2: Developer Support
├── Tests become complex (auth, encryption, business rules)
├── QA needs custom assertions they can't write
├── Developers create components, QA uses them
└── External libraries for components

Stage 3: Mixed Workflows
├── Some tests stay visual (QA maintains)
├── Complex tests written as code (developers maintain)
├── Both run together, unified reporting
└── External libraries for components + test cases

The Future: AI-Powered Testing

AI coding assistants are changing the landscape:

Writing test code is faster than ever (Copilot, Cursor, Claude)
Code-driven tests becoming more practical
But QA still needs visual tools for execution and monitoring

External libraries let you embrace code-driven testing while keeping QA in the loop.

The Benefits: Clear Separation of Concerns

External libraries create a clean division of responsibilities:

For Developers

What You Do	What You Don’t Touch
Write code in your IDE	Environment configuration
Use AI assistants freely	Server/auth setup
Unit test locally	Test scheduling
`npm run build && reapi sync`	Notifications
Done.	Reporting & dashboards

Your workflow:

Code → Test locally → Build → Sync → Done

That’s it. No clicking around in UIs, no configuring environments, no setting up auth tokens.

For QA

What You Control	What You Don’t Need
Which tests to run	Coding skills
Environment & server selection	IDE setup
Variable groups & secrets	npm/TypeScript knowledge
Test scheduling	Git workflows
Notifications & alerts	Build processes
Results monitoring

Your workflow:

Select test cases (by name or tags like “smoke”, “regression”)
Choose environment (staging, production)
Run on-demand or schedule
Monitor results, get notified on failures

The Deal

Developers own the code. QA owns the execution.

Developers focus on writing quality test logic with proper engineering practices. QA focuses on when, where, and how tests run—plus monitoring and reporting.

Neither needs to understand the other’s domain deeply. The platform bridges both worlds.

Choose Your Workflow

Workflow A: QA-Only (Web Editor)

Best for: Small teams, simple APIs, getting started

QA Team
   │
   ▼
┌─────────────────────────┐
│  Web Editor             │
│  • Visual test builder  │
│  • Built-in assertions  │
│  • Simple generators    │
└─────────────────────────┘

Pros: No coding required, fast to start
Cons: Limited for complex logic

Workflow B: Developer-Empowered QA

Best for: Teams with complex validation needs, scaling test coverage

Developers create reusable components that QA uses in visual flows:

Developer                              QA Team
    │                                     │
    ▼                                     │
┌────────────────────┐                    │
│ Write components   │                    │
│ • Assertions       │                    │
│ • Generators       │                    │
│ • API hooks        │                    │
└─────────┬──────────┘                    │
          │                               │
          ▼                               │
┌────────────────────┐                    │
│ Deploy & Register  │                    │
└─────────┬──────────┘                    │
          │                               │
          ▼                               ▼
┌───────────────────────────────────────────┐
│            ReAPI Platform                  │
│  ┌─────────────────────────────────────┐  │
│  │ QA builds visual tests using:       │  │
│  │ • Developer-created assertions      │  │
│  │ • Developer-created generators      │  │
│  │ • Visual API nodes                  │  │
│  └─────────────────────────────────────┘  │
└───────────────────────────────────────────┘

Example: Developer creates isValidIBAN assertion → QA uses it from dropdown in Assert Node

Pros: QA stays visual, complex logic handled by developers
Cons: Requires developer involvement for new components

Workflow C: Code-Driven Tests + Visual Orchestration

Best for: Developer-heavy teams, complex test scenarios, AI-assisted testing

Developers write complete test cases as code. QA orchestrates and runs them:

Developer                              QA Team
    │                                     │
    ▼                                     │
┌────────────────────┐                    │
│ Write test cases   │                    │
│ • Full test logic  │                    │
│ • Tagged by feature│                    │
│ • TypeScript/IDE   │                    │
└─────────┬──────────┘                    │
          │                               │
          ▼                               │
┌────────────────────┐                    │
│ Deploy & Register  │                    │
└─────────┬──────────┘                    │
          │                               │
          ▼                               ▼
┌───────────────────────────────────────────┐
│            ReAPI Platform                  │
│  ┌─────────────────────────────────────┐  │
│  │ QA builds flows using:              │  │
│  │ • External Test Case nodes          │  │
│  │ • Tag-based test selectors          │  │
│  │ • Visual API nodes (mixed)          │  │
│  │                                     │  │
│  │ QA manages:                         │  │
│  │ • Environments & variables          │  │
│  │ • Test scheduling                   │  │
│  │ • Results & reporting               │  │
│  └─────────────────────────────────────┘  │
└───────────────────────────────────────────┘

Example: Developer writes paymentFlowTest with tag ["payments", "smoke"] → QA adds “Run all smoke tests” selector node to flow

Pros: Full developer tooling, AI-assisted coding, proper engineering practices
Cons: Requires developer to write tests

Workflow D: Hybrid (Most Teams)

Best for: Mature teams, balancing speed and quality

Combine all approaches based on test complexity:

Test Type	Who Creates	How
Simple API checks	QA	Visual nodes
Complex validations	QA (using dev components)	Visual + custom assertions
Business logic tests	Developers	External test cases
E2E workflows	Both	Mixed flows

┌─────────────────────────────────────────────────────────────┐
│                      Test Flow                               │
├─────────────────────────────────────────────────────────────┤
│  ┌──────────────┐                                           │
│  │ Visual Node  │ ◀── QA: Setup API call                    │
│  │ POST /setup  │                                           │
│  └──────┬───────┘                                           │
│         │                                                   │
│         ▼                                                   │
│  ┌──────────────┐                                           │
│  │ External     │ ◀── Developer: Complex auth flow          │
│  │ Test Case    │                                           │
│  └──────┬───────┘                                           │
│         │                                                   │
│         ▼                                                   │
│  ┌──────────────┐                                           │
│  │ Visual Node  │ ◀── QA: Verify with custom assertion      │
│  │ + Custom     │     (developer-created)                   │
│  │ Assertion    │                                           │
│  └──────────────┘                                           │
└─────────────────────────────────────────────────────────────┘

Deciding What’s Right for Your Team

If your team…	Start with…	Consider later…
Is QA-only, simple APIs	Web editor only	Components when needed
Has developers available	Workflow B (components)	Test cases for complex flows
Prefers code over UI	Workflow C (test cases)	Let QA handle orchestration
Is scaling rapidly	Workflow D (hybrid)	Formalize component library
Uses AI for coding	Workflow C or D	Code-driven with QA oversight

Transitioning Between Workflows

From A → B (Adding Developer Components)

Identify complex assertions QA struggles with
Developer creates external library with those components
QA starts using them in existing visual flows
Gradually add more components as needed

From B → C (Adding Code-Driven Tests)

Developer adds $$TestCases export to existing library
Write complex test scenarios as code
QA adds External Test Case nodes to flows
Visual and code tests run together

From Any → D (Full Hybrid)

Audit existing tests: what’s simple vs complex?
Keep simple tests visual
Migrate complex logic to external library
Establish conventions for when to use each approach

What External Libraries Provide

Component	Purpose	Who Creates	Who Uses
Assertions	Custom validation logic	Developer	QA (in Assert nodes)
Generators	Dynamic test data	Developer	QA (in Context ops)
API Hooks	Request/response modification	Developer	QA (attach to flows)
Utilities	Shared helper functions	Developer	Both
Test Cases	Complete test functions	Developer	QA (in Test Case nodes)

Next Steps

Choose your path:

Just getting started? → Getting Started
Need to create components for QA? → Writing Components
Want code-driven tests? → External Test Cases
Setting up dev workflow? → Developer Workflow

Custom Assertions How It Works