AutoBE
    Preparing search index...

    Interface IErrorPredicate

    General error validation predicate for TestValidator assertion.

    Generates TestValidator.error() call to verify that operations correctly throw errors under specific conditions. Used for testing error handling, business rule violations, and validation of both general errors and HTTP-specific error conditions in API operations.

    Preferred over manual error testing: Use this instead of IIfStatement with throw statements or try-catch blocks for error validation.

    E2E testing scenarios:

    • Testing business logic validation errors
    • Verifying general exception handling in utility functions
    • Confirming error throwing for invalid business operations
    • Testing HTTP status code responses from API operations (400, 401, 403, 404, etc.)
    • Testing authentication failures and authorization errors
    • Validating API request validation errors and conflict responses

    AI function calling usage: Use when business scenarios should intentionally fail to test error handling, including both general errors and specific HTTP status code validation from API operations.

    interface IErrorPredicate {
        function: IArrowFunction;
        title: string & MinLength<1>;
        type: "errorPredicate";
    }
    Index

    Properties

    function title type

    Properties

    function: IArrowFunction

    Arrow function containing the operation that should throw an error.

    Encapsulates the API operation or business logic that is expected to fail. The function should contain realistic API operations (using IApiOperateStatement within the function body) with invalid data or conditions that trigger appropriate error responses.

    Note: The function body can contain IApiOperateStatement calls since this is specifically for testing API error conditions.

    General Error Testing Patterns:

    • API calls with invalid business data that should trigger general errors
    • API operations with malformed or missing required data
    • Business rule violations that should be rejected by API operations
    • General validation failures and custom error conditions

    HTTP Error Testing Patterns:

    Authentication Errors (401):

    • API calls with invalid or expired tokens
    • Login attempts with wrong credentials
    • Access without required authentication headers

    Authorization Errors (403):

    • API calls with insufficient user permissions
    • Access to restricted resources by unauthorized users
    • Operations requiring admin privileges by regular users

    Validation Errors (400, 422):

    • API calls with missing required fields
    • Invalid data format or type in request body
    • Business rule violations in API parameters

    Not Found Errors (404):

    • API calls with non-existent resource IDs
    • Access to deleted or unavailable resources
    • Invalid endpoint or resource paths

    Conflict Errors (409):

    • Duplicate resource creation attempts
    • Concurrent modification conflicts
    • Business rule conflicts (e.g., duplicate emails)

    Rate Limiting Errors (429):

    • Excessive API calls within time window
    • Quota exceeded for API operations
    • Throttling due to usage limits

    Server Errors (5xx):

    • API calls that trigger internal server errors
    • Operations that cause service unavailability
    • Database connection or processing failures

    AI function construction: Create realistic error scenarios that test actual business constraints and error handling. Focus on API operation error conditions that should throw errors, including both general exceptions and specific HTTP status code responses.

    title: string & MinLength<1>

    Descriptive title explaining the error condition being tested.

    🚨 CRITICAL: This MUST be a simple string value, NOT an expression! 🚨

    ❌ WRONG - DO NOT use expressions of any kind:

    • { type: "binaryExpression", operator: "+", left: "Should fail", right: " with invalid data" }
    • { type: "stringLiteral", value: "some string" }
    • Any IExpression types - this is NOT an expression field!

    ✅ CORRECT - Use direct string values only:

    • "Should fail business validation with invalid data"
    • Simple, complete descriptive text as a raw string

    Should clearly describe what error is expected and why it should occur. This helps understand the negative test case purpose and assists with debugging when expected errors don't occur.

    Examples:

    General Error Testing:

    • "Should fail business validation with invalid data"
    • "Should throw error for duplicate entity creation"
    • "Should reject operation with insufficient business context"
    • "Should validate required business rule constraints"

    HTTP Error Testing:

    • "Should return 401 for invalid authentication credentials"
    • "Should return 403 for unauthorized customer access"
    • "Should return 400 for missing required fields in registration"
    • "Should return 404 for non-existent product ID"
    • "Should return 409 for duplicate email registration"
    • "Should return 422 for invalid business data format"
    • "Should return 429 for rate limit exceeded"

    AI title strategy: Focus on the specific error condition and business context that should trigger the failure. Include HTTP status codes when testing API error responses for clarity and debugging assistance.

    type: "errorPredicate"

    Type discriminator.

    Settings

    Member Visibility

    On This Page

    Properties