Task 1 — Configurable String Validation

Objective

Create a reusable validation function that validates a collection of strings according to configurable validation rules.

The system must support seven different validation types.

A validation failure may contain multiple errors for the same input value.

Validation Types

Define the following validation types.

Type 1 — Printable Characters

All printable characters are allowed.

The value must still satisfy configured:

• length limits
• whitespace rules

Type 2 — ID

Allowed characters are:

A-Z
a-z
0-9
-
_

No other characters are allowed.

Type 3 — Phone Number

The value must represent a valid phone-number format.

The exact accepted phone syntax should be explicitly defined by the implementation.

At minimum, the validator should distinguish phone numbers from arbitrary text.

Type 4 — Digits Only

Only decimal digits are allowed:

0-9

Type 5 — Letters and Selected Special Characters

Allowed characters are:

A-Z
a-z
-
_
$
!
#

Digits are not allowed.

Type 6 — UTC Timeline

The value must represent a valid UTC timestamp.

For example:

2019-11-27T18:00:00Z

A practical implementation may use an RFC 3339 compatible UTC representation.

Type 7 — IP Address

The value must represent either:

IPv4

or:

IPv6

Validation Configuration

Every validation request must support additional configuration.

A possible model is:

type ValidationType int

type ValidationRule struct {
    Type              ValidationType
    Description       string
    MinLength         int
    MaxLength         int
    AllowWhitespace   bool
    MaxWhitespace     int
}

The exact structure may be changed, but equivalent information must be supported.

Description

Every value should have a description explaining what is being validated.

For example:

ValidationRule{
    Description: "User identifier",
}

This description should also be available in validation errors.

Length Validation

Each validation rule must support:

minimum number of characters
maximum number of characters

For example:

MinLength = 3
MaxLength = 32

means:

3 <= length <= 32

Whitespace Validation

Every rule must define whether whitespace is allowed.

When whitespace is allowed, the configuration must also specify the maximum number of whitespace characters.

For example:

AllowWhitespace: true,
MaxWhitespace:   2,

allows at most two whitespace characters.

If:

AllowWhitespace: false,

any whitespace occurrence is a validation error.

Input

The validator must be able to process a slice of strings.

A useful request model is:

type ValidationInput struct {
    Value string
    Rule  ValidationRule
}

Multiple values can then be validated using:

[]ValidationInput

Result Model

Use structured validation errors.

For example:

type ValidationError struct {
    Description string
    Rule        string
    Message     string
}

A complete result may be:

type ValidationResult struct {
    Valid  bool
    Errors []ValidationError
}

Multiple Errors

The validator must not stop after the first failed rule.

For example, suppose an ID:

"ab @"

must satisfy:

Type = ID
MinLength = 8
Whitespace = forbidden

The result may contain several errors:

minimum length not satisfied
invalid character '@'
whitespace is not allowed

All applicable validation errors should be returned.

Example — Valid ID

Configuration:

ValidationRule{
    Type:            ValidationTypeID,
    Description:     "User ID",
    MinLength:       3,
    MaxLength:       20,
    AllowWhitespace: false,
}

Value:

dev_user-01

Expected result:

valid

Example — Invalid ID

Value:

dev user@01

Possible errors include:

whitespace is not allowed
character '@' is not allowed

UTC Validation

A UTC timeline should be parsed and verified rather than accepted only because it superficially resembles a timestamp.

For example:

2019-11-27T18:00:00Z

is valid.

A malformed date such as:

2019-99-77T81:00:00Z

must not pass validation.

IPv4 and IPv6

Type 7 should validate actual address structure.

Examples:

192.168.1.10

and:

2001:db8::1

represent different supported address families.

Phone Validation

The original task requires a phone-number validation type but does not define one exact international phone-number grammar.

Therefore, the accepted syntax must be documented by the implementation.

Do not silently invent several incompatible phone formats.

One reasonable implementation may support a normalized international representation such as:

+381641234567

while separately deciding whether spaces or separators are allowed through the configured rules.

Configuration Validation

The validation configuration itself must also be valid.

Examples of invalid configuration include:

MinLength < 0
MaxLength < MinLength
MaxWhitespace < 0

These should be rejected before validating values.

Requirements

The validator must:

1. support all seven validation types
2. support minimum and maximum length
3. support configurable whitespace behavior
4. include a description for every analyzed value
5. return multiple errors when multiple rules fail
6. process multiple input values
7. distinguish configuration errors from value-validation errors

Testing

Create multiple tests.

At minimum, test:

• valid Type 1 value
• invalid ID
• valid and invalid phone numbers
• digits-only success and failure
• Type 5 allowed and forbidden characters
• valid and malformed UTC values
• valid IPv4
• invalid IPv4
• valid IPv6
• invalid IPv6
• minimum-length failure
• maximum-length failure
• forbidden whitespace
• excessive whitespace
• multiple simultaneous errors

Implementation Notes

The validator should be reusable by later tasks.

In particular, Task 2 requires validation of user attributes when users are inserted into the store.

Avoid writing a validator that only works with the example values from this task.