Preparing for Laravel Developer role at 9H

Laravel's Service Container is a powerful IoC (Inversion of Control) container that manages class dependencies and performs dependency injection. In the context of legacy application rewriting, it's particularly valuable because:

1. Automatic Resolution:

public function __construct(
    private UserRepository $userRepository,
    private Logger $logger
) {
    // Dependencies automatically resolved
}

2. Service Binding:

// In ServiceProvider
public function register()
{
    $this->app->bind(UserRepositoryInterface::class, function ($app) {
        return new UserRepository($app->make(Database::class));
    });
}

3. Singleton Binding:

$this->app->singleton(CacheManager::class, function ($app) {
    return new CacheManager($app);
});

This is especially important for the project as it allows for easy swapping of implementations when transitioning from legacy code to new components, maintaining loose coupling throughout the system.

For the legacy application rewrite, the Repository Pattern would be instrumental in separating data access logic from business logic:

1. Interface Definition:

interface UserRepositoryInterface
{
    public function find(int $id): ?User;
    public function findByEmail(string $email): ?User;
    public function save(User $user): void;
}

2. Concrete Implementation:

class EloquentUserRepository implements UserRepositoryInterface
{
    public function find(int $id): ?User
    {
        return User::find($id);
    }
    
    public function findByEmail(string $email): ?User
    {
        return User::where('email', $email)->first();
    }
    
    public function save(User $user): void
    {
        $user->save();
    }
}

3. Service Provider Registration:

$this->app->bind(UserRepositoryInterface::class, EloquentUserRepository::class);

Benefits particularly relevant to the project:

• Easier migration from legacy data sources
• Consistent data access layer
• Simplified unit testing
• Cleaner separation of concerns

Event broadcasting in Laravel is crucial for building real-time applications. In the context of a legacy system rewrite, it can be used to:

1. Event Definition:

class UserRegistered implements ShouldBroadcast
{
    public function __construct(private User $user)
    {}

    public function broadcastOn(): array
    {
        return ['user-notifications'];
    }
}

2. Broadcasting Configuration:

// Broadcasting with Redis for scalability
'redis' => [
    'driver' => 'redis',
    'connection' => 'default',
    'queue' => 'broadcast',
],

Use cases relevant to the project:

• Real-time notifications for system updates
• Live data synchronization during migration
• User activity monitoring
• Async processing of legacy data imports

For a legacy system rewrite, proper transaction handling is critical for data integrity:

1. Basic Transaction:

DB::transaction(function () {
    DB::table('users')->update(['active' => false]);
    DB::table('logs')->insert(['message' => 'Users deactivated']);
});

2. Manual Transaction Control:

try {
    DB::beginTransaction();
    // Complex legacy data migration logic
    DB::commit();
} catch (\Exception $e) {
    DB::rollBack();
    Log::error('Migration failed: ' . $e->getMessage());
}

Best practices:

• Use automatic deadlock retry
• Implement proper error handling
• Keep transactions as short as possible
• Consider using database locks for critical operations
• Implement proper logging for transaction failures

Service providers are the backbone of Laravel's bootstrapping process. For a legacy system rewrite, they're essential for:

1. Custom Service Provider:

class LegacyDataServiceProvider extends ServiceProvider
{
    public function register()
    {
        $this->app->singleton(LegacyDataConnector::class);
    }

    public function boot()
    {
        $this->loadMigrationsFrom(__DIR__ . '/migrations');
        $this->publishes([
            __DIR__ . '/config' => config_path('legacy'),
        ]);
    }
}

Key responsibilities:

• Database connection management
• Third-party service integration
• Configuration publishing
• Migration registration
• Event listener registration

For the legacy rewrite project, DDD would help organize complex business logic:

1. Domain Layer Structure:

app/
  Domain/
    User/
      Actions/
      Events/
      Models/
      ValueObjects/
      Repositories/
    Billing/
      Actions/
      Services/
      Aggregates/

2. Example Domain Service:

class UserRegistrationService
{
    public function register(UserDTO $userData): User
    {
        $user = $this->userFactory->create($userData);
        $this->userRepository->save($user);
        event(new UserRegistered($user));
        return $user;
    }
}

Key implementations:

• Bounded contexts for different business domains
• Rich domain models
• Value objects for immutable concepts
• Domain events for cross-boundary communication

Middleware is crucial for request/response handling, especially important for legacy system integration:

1. Custom Middleware Example:

class LegacyAuthenticationMiddleware
{
    public function handle($request, Closure $next)
    {
        if ($this->isLegacyUser($request)) {
            // Handle legacy authentication
            return $this->handleLegacyAuth($request);
        }
        return $next($request);
    }
}

Practical applications for the project:

• Authentication bridging between old and new systems
• Request logging for migration debugging
• API rate limiting
• Response transformation for legacy clients
• Cross-Origin Resource Sharing (CORS) handling

1. System Documentation Review:

• Gather all existing documentation
• Review business rules and workflows
• Identify integration points

2. Code Analysis:

• Use static code analysis tools
• Document system architecture
• Identify dependencies

3. Stakeholder Workshops:

• Since the job requires running client workshops, I would organize sessions with:
  • Business stakeholders to understand critical workflows
  • End users to identify pain points
  • Technical team to understand technical debt

4. Database Analysis:

• Map data relationships
• Identify data quality issues
• Document database schema

5. Create Migration Strategy Document:

• Risk assessment
• Timeline planning
• Resource allocation
• Success metrics

Given that the legacy system is Microsoft Access-based (mentioned in bonus skills), I would:

1. Create ETL Pipeline:

• Build Laravel commands for extraction
• Use Laravel's Database migrations for schema creation
• Implement data transformers using Laravel's collections

2. Implement Migration Process:

class DataMigrationService
{
    public function migrate()
    {
        DB::beginTransaction();
        try {
            // Extract from legacy system
            $legacyData = $this->extractFromLegacy();
            
            // Transform data
            $transformedData = $this->transformData($legacyData);
            
            // Load into new system
            $this->loadData($transformedData);
            
            DB::commit();
        } catch (Exception $e) {
            DB::rollBack();
            Log::error('Migration failed: ' . $e->getMessage());
        }
    }
}

3. Use Queue System:

• Break migration into chunks
• Use Laravel's queue system for processing
• Implement retry mechanisms

1. Parallel Operation Strategy:

• Keep legacy system running
• Implement synchronization mechanism
• Use event-driven architecture for real-time updates

2. Staged Migration:

class StagedMigrationService
{
    public function migrateInStages()
    {
        // Stage 1: Read-only migration
        $this->migrateHistoricalData();
        
        // Stage 2: Sync new operations
        $this->enableSynchronization();
        
        // Stage 3: Switchover
        $this->performSwitchover();
    }
}

3. Feature Flags:

• Use Laravel's configuration system
• Implement gradual rollout
• Enable quick rollback capability

4. Monitoring:

• Implement health checks
• Set up error tracking
• Monitor system performance

1. Automated Testing:

class DataValidationTest extends TestCase
{
    public function testDataIntegrity()
    {
        $legacyRecord = LegacyDB::first();
        $migratedRecord = NewDB::where('legacy_id', $legacyRecord->id)->first();
        
        $this->assertEquals(
            $this->normalizeData($legacyRecord),
            $this->normalizeData($migratedRecord)
        );
    }
}

2. Validation Tools:

• Checksums for data integrity
• Database comparison tools
• Custom validation scripts

3. Business Logic Validation:

• Unit tests for business rules
• Integration tests for workflows
• End-to-end testing scenarios

4. Manual Verification:

• Sample data review
• Business stakeholder validation
• User acceptance testing

1. Data Transformation Layer:

class DataTypeTransformer
{
    public function transform($data, $sourceType, $targetType)
    {
        return match($sourceType) {
            'access_datetime' => Carbon::createFromFormat('...', $data),
            'access_currency' => $this->transformCurrency($data),
            default => $this->defaultTransform($data)
        };
    }
}

2. Type Casting Strategy:

• Define type mapping rules
• Implement validation rules
• Handle edge cases

3. Data Cleaning:

• Normalize data formats
• Handle null values
• Clean invalid characters

4. Error Handling:

• Log transformation errors
• Implement fallback values
• Report transformation issues

1. Domain-Driven Design Approach:

• Identify bounded contexts
• Define domain models
• Create service boundaries

2. Modular Architecture:

// Example of a modular service structure
namespace App\Modules\Billing;

class BillingService
{
    public function __construct(
        private PaymentGateway $gateway,
        private InvoiceRepository $invoices
    ) {}
    
    public function processPayment(Order $order)
    {
        // Implementation
    }
}

3. Implementation Strategy:

• Start with highest business value modules
• Use Laravel's service container for dependency management
• Implement SOLID principles

4. Communication Pattern:

• Define clear interfaces
• Use events for loose coupling
• Implement API contracts

5. Database Strategy:

• Consider separate databases per module
• Implement data consistency patterns
• Use Laravel's database transactions

For large datasets, I employ several optimization strategies:

1. Proper indexing based on query patterns
2. Using EXPLAIN to analyze query execution plans
3. Implementing database partitioning for tables exceeding 1M rows
4. Using compound indexes for frequently combined conditions
5. Implementing query caching with Redis for read-heavy operations
6. Breaking down complex queries into smaller, more manageable ones
7. Using LIMIT and offset for pagination instead of SELECT *
8. Considering denormalization where appropriate for read performance

Given the project's requirement to rewrite a legacy application, I would also analyze existing query patterns to identify optimization opportunities during the migration.

My approach to scalable database design includes:

1. Proper normalization (typically to 3NF) while considering practical performance trade-offs
2. Implementation of appropriate primary and foreign keys
3. Using appropriate data types (e.g., UNSIGNED for positive numbers only)
4. Implementing vertical partitioning for tables with many columns
5. Using ENUM for fixed sets of values
6. Creating intermediate tables for many-to-many relationships
7. Using UUID for distributed systems
8. Implementing appropriate indexes based on access patterns

Since this role involves rewriting a legacy application, I would analyze the existing schema for pain points and design the new schema to address current scalability issues while anticipating future growth.

My indexing strategy includes:

1. PRIMARY KEY indexing for unique record identification
2. Creating composite indexes for frequently combined WHERE clauses
3. Using covering indexes to optimize SELECT queries
4. Implementing UNIQUE indexes for columns requiring uniqueness
5. Adding indexes on foreign key columns
6. Using partial indexes for filtered queries
7. Regular index maintenance and cleanup

When migrating from a legacy system, I would:

• Analyze existing query patterns
• Review current index usage with tools like MySQL's sys schema
• Create new indexes based on actual query patterns
• Remove redundant or unused indexes

For production database migrations, I follow these steps:

1. Use Laravel's migration system for version control of schema changes
2. Implement zero-downtime migrations:
   • Add new tables/columns without removing old ones
   • Deploy code that can work with both old and new schemas
   • Migrate data in small batches
   • Remove old schema elements after confirming stability
3. Always create backup points before migrations
4. Test migrations in staging environment first
5. Schedule migrations during low-traffic periods
6. Use database transactions for atomic changes
7. Implement rollback plans for each migration

Given the project's legacy system migration requirement, I would ensure minimal disruption to business operations during the transition.

My experience includes:

1. Using EXPLAIN ANALYZE to identify query execution bottlenecks
2. Implementing proper indexing strategies based on query patterns
3. Optimizing JOIN operations:
   • Using appropriate JOIN types (INNER, LEFT, etc.)
   • Ordering JOINs for optimal execution
4. Query rewriting:
   • Converting subqueries to JOINs where beneficial
   • Using EXISTS instead of IN for better performance
5. Implementing caching strategies:
   • Query cache
   • Result cache using Redis
6. Regular monitoring and optimization of slow queries
7. Using tools like MySQL Workbench and Percona Toolkit for analysis

For the legacy application rewrite, I would apply these techniques to ensure the new system performs better than the original.

I implement data partitioning through:

1. Range Partitioning:
   • For date-based data
   • For numerical ranges
2. List Partitioning:
   • For categorical data
   • For geographic distribution
3. Hash Partitioning:
   • For even data distribution
   • When natural partitioning keys aren't available
4. Composite Partitioning:
   • Combining different partitioning strategies

Implementation considerations:

• Analyzing data access patterns
• Determining partition size for optimal performance
• Regular maintenance of partitions
• Monitoring partition pruning effectiveness

This would be particularly relevant when migrating large datasets from the legacy system to ensure optimal performance in the new application.

To maintain data integrity, I employ:

1. ACID compliance through:
   • Proper transaction management
   • Using Laravel's DB::transaction()
   • Implementing appropriate isolation levels
2. Implementing database constraints:
   • Foreign key constraints
   • Unique constraints
   • Check constraints
3. Using database locks when necessary:
   • Row-level locking
   • Table-level locking
4. Implementing retry mechanisms for deadlock situations
5. Following the Unit of Work pattern
6. Using optimistic locking for concurrent updates
7. Regular data validation and consistency checks

For the legacy system migration, this would be crucial to ensure no data is lost or corrupted during the transition process.

In Laravel applications, I implement SRP by ensuring each class has one specific purpose. For example, in a legacy system rewrite (as mentioned in the job description), I would:

1. Create separate service classes for distinct business logic
2. Use dedicated repository classes for database operations
3. Implement form request classes for validation logic
4. Utilize event classes for specific events
5. Use job classes for queue processing

Example:

// Instead of putting everything in controller
class UserController {
    public function store(StoreUserRequest $request, UserService $userService) 
    {
        $user = $userService->createUser($request->validated());
        event(new UserCreated($user));
        return new UserResource($user);
    }
}

This approach ensures better maintainability and easier testing of the legacy system rewrite.

Dependency injection is a technique where a class receives its dependencies through constructor injection, method injection, or property injection rather than creating them internally. In the context of Laravel's Service Container:

class LegacyDataMigrationService {
    private UserRepository $userRepository;
    private Logger $logger;

    public function __construct(
        UserRepository $userRepository,
        Logger $logger
    ) {
        $this->userRepository = $userRepository;
        $this->logger = $logger;
    }
}

This achieves loose coupling by:

1. Making dependencies explicit
2. Allowing easy dependency substitution
3. Facilitating testing through mocking
4. Enabling interface-based programming
5. Making the code more maintainable and flexible

This is particularly important for the legacy application rewrite mentioned in the job description, as it allows for easier testing and future modifications.

ISP states that clients shouldn't be forced to depend on interfaces they don't use. In the context of a legacy system rewrite:

// Instead of one large interface
interface LegacyDataHandler {
    public function read(): array;
    public function write(array $data): void;
    public function validate(): bool;
    public function transform(): array;
}

// Break it into smaller, focused interfaces
interface DataReader {
    public function read(): array;
}

interface DataWriter {
    public function write(array $data): void;
}

interface DataValidator {
    public function validate(): bool;
}

// Classes can implement only what they need
class LegacyFileReader implements DataReader {
    public function read(): array {
        // Implementation
    }
}

This approach:

1. Reduces coupling
2. Increases cohesion
3. Makes the system more maintainable
4. Allows for better unit testing
5. Facilitates gradual legacy system migration

In the context of a legacy system rewrite, I implemented OCP when designing a notification system:

abstract class NotificationChannel {
    abstract public function send(string $message): void;
}

class EmailNotification extends NotificationChannel {
    public function send(string $message): void {
        // Email implementation
    }
}

class SMSNotification extends NotificationChannel {
    public function send(string $message): void {
        // SMS implementation
    }
}

// Adding new channel doesn't require modifying existing code
class SlackNotification extends NotificationChannel {
    public function send(string $message): void {
        // Slack implementation
    }
}

This design:

1. Allows adding new notification channels without modifying existing code
2. Makes the system extensible
3. Maintains backward compatibility
4. Facilitates testing
5. Supports gradual feature migration from legacy systems

PHP 8.3 offers several features that enhance code maintainability:

1. Type Declaration Improvements:

class UserService {
    public function findUser(readonly string $id): ?User {
        return User::find($id);
    }
}

2. Anonymous Classes with Constructor Parameters:

$logger = new class('app.log') implements LoggerInterface {
    public function __construct(private string $logFile) {}
    // Implementation
};

3. Typed Class Constants:

class Config {
    public const string DEFAULT_LOCALE = 'en';
    public const int CACHE_DURATION = 3600;
}

4. Override Attribute:

class LegacyUserRepository extends BaseRepository {
    #[Override]
    public function find(int $id): ?User {
        // Implementation
    }
}

These features help create more robust and self-documenting code, which is crucial for maintaining a large-scale application like the one mentioned in the job description.

For the legacy system rewrite, I would implement the Repository pattern as follows:

interface UserRepositoryInterface {
    public function find(int $id): ?User;
    public function create(array $data): User;
    public function update(int $id, array $data): bool;
    public function delete(int $id): bool;
}

class EloquentUserRepository implements UserRepositoryInterface {
    public function find(int $id): ?User {
        return User::find($id);
    }
    
    // Other implementations
}

// For legacy system
class LegacyUserRepository implements UserRepositoryInterface {
    public function find(int $id): ?User {
        // Legacy system specific implementation
    }
    
    // Other implementations
}

// In service provider
class RepositoryServiceProvider extends ServiceProvider {
    public function register(): void {
        $this->app->bind(UserRepositoryInterface::class, 
            EloquentUserRepository::class);
    }
}

This approach:

1. Provides a consistent interface for data access
2. Facilitates switching between different implementations
3. Makes testing easier through dependency injection
4. Enables gradual migration from legacy systems
5. Maintains clean separation of concerns

For this legacy application rewrite project, I would implement a robust CI/CD pipeline using GitHub Actions or GitLab CI, with the following stages:

1. Build Stage:

• Composer install with optimization
• NPM install and asset compilation
• Generate application key
• Cache configuration

2. Test Stage:

• Static code analysis (PHPStan)
• PHP CS Fixer for code style
• Unit tests
• Feature tests
• Integration tests

3. Deploy Stage:

• Environment validation
• Database backup
• Artisan down
• Deploy new code
• Run migrations
• Cache clearing
• Artisan up

The pipeline would integrate with the specified cloud platforms (AWS/Azure/Google Cloud) as mentioned in the bonus skills, ensuring automated deployments while maintaining code quality and testing standards.

For Laravel applications, I create a Docker environment with multiple containers:

1. Application container:

• PHP 8.3 with required extensions
• Composer
• Laravel-specific configurations

2. Web Server container (Nginx)
3. Database container (MySQL/MariaDB as per project requirements)
4. Redis container for caching
5. Queue worker container for background jobs

The setup includes:

• docker-compose.yml for local development
• Dockerfile optimized for production
• Volume mappings for persistent data
• Network configuration for container communication

This containerized approach ensures consistent environments across development, staging, and production, which is crucial for the legacy application rewrite project mentioned in the job description.

For handling database migrations in a CI/CD pipeline, especially for a legacy system rewrite, I implement the following strategy:

1. Pre-deployment:

• Automated backup of the current database
• Validation of migration files
• Dry-run of migrations in a staging environment

2. During deployment:

• Run migrations with --force flag
• Transaction wrapping for rollback capability
• Schema validation checks

3. Post-deployment:

• Verification of migration success
• Data integrity checks
• Performance validation of new schema

Additional safety measures:

• Maintaining backward compatibility
• Using database transactions
• Implementing rollback procedures
• Version control for migrations

This approach ensures safe database schema updates while maintaining data integrity during the transition from the legacy system.

For zero-downtime deployments, especially crucial when rewriting a business-critical application, I implement:

1. Blue-Green Deployment:

• Maintain two identical production environments
• Deploy to inactive environment
• Switch traffic after validation
• Keep previous version for quick rollback

2. Implementation Steps:

• Load balancer configuration
• Database replication setup
• Session handling strategy
• Cache warming
• Health checks

3. Deployment Process:

• Deploy new code to inactive environment
• Run migrations
• Verify application health
• Gradually shift traffic (canary deployment)
• Monitor for errors
• Complete cutover when stable

This approach ensures business continuity and minimizes risk during the legacy system transition.

For secure environment management across deployment stages:

1. Secret Management:

• Use AWS Secrets Manager/Azure Key Vault
• Implement encryption at rest
• Rotate credentials regularly
• Use different keys per environment

2. Environment Variables:

• .env files for local development
• CI/CD platform secret storage
• Environment-specific configurations
• Validation of required variables

3. Access Control:

• Role-based access to secrets
• Audit logging
• Separate credentials per environment
• Automated secret rotation

This approach ensures secure handling of sensitive data while maintaining flexibility across development, staging, and production environments, which is essential for the legacy application rewrite project.

For production monitoring, I implement a comprehensive strategy:

1. Application Monitoring:

• Laravel Telescope for development
• New Relic or Datadog for production
• Custom logging for business-critical operations
• Exception tracking with Sentry

2. Performance Metrics:

• Response time monitoring
• Database query performance
• Cache hit rates
• Queue processing times
• Memory usage
• CPU utilization

3. Alerting System:

• Define critical thresholds
• Alert routing based on severity
• Integration with team communication tools
• Automated incident response

4. Business Metrics:

• User activity monitoring
• Transaction success rates
• API endpoint usage
• Custom metrics for business KPIs

This comprehensive monitoring approach ensures high availability and performance of the rewritten application, meeting the project's business-critical requirements.

In Laravel applications, I follow these key principles for unit testing:

1. Use PHPUnit with Laravel's TestCase class
2. Focus on testing individual components in isolation
3. Implement test doubles (mocks/stubs) for dependencies
4. Follow the AAA (Arrange-Act-Assert) pattern
5. Use data providers for testing multiple scenarios
6. Specifically for legacy application rewrite, I create parallel tests to ensure both systems produce identical results during migration

Example:

public function test_user_service_creates_user()
{
    // Arrange
    $userData = ['name' => 'Test User', 'email' => '[email protected]'];
    $userRepositoryMock = $this->mock(UserRepository::class);
    $userRepositoryMock->shouldReceive('create')->once()->with($userData);

    // Act
    $userService = new UserService($userRepositoryMock);
    $result = $userService->createUser($userData);

    // Assert
    $this->assertTrue($result);
}

For feature testing, especially in a legacy system rewrite context:

1. Focus on end-to-end business workflows
2. Test critical user journeys first
3. Use Laravel's HTTP testing methods for API endpoints
4. Implement database transactions for test isolation
5. Create parallel tests comparing legacy and new system behaviors

Example:

public function test_user_registration_workflow()
{
    // Simulate user registration
    $response = $this->postJson('/api/register', [
        'name' => 'Test User',
        'email' => '[email protected]',
        'password' => 'password'
    ]);

    $response->assertStatus(201)
             ->assertJsonStructure(['id', 'name', 'email']);

    // Verify database state
    $this->assertDatabaseHas('users', [
        'email' => '[email protected]'
    ]);
}

For mocking external services, I use:

1. Laravel's built-in mocking facilities
2. Facade mocks for Laravel services
3. Mock HTTP responses using Laravel's HTTP facades
4. Service container bindings for dependency injection

Example:

public function test_external_api_integration()
{
    Http::fake([
        'api.external-service.com/*' => Http::response([
            'status' => 'success'
        ], 200)
    ]);

    // Test your service
    $response = $this->get('/api/external-data');
    $response->assertStatus(200);

    Http::assertSent(function ($request) {
        return $request->url() === 'api.external-service.com/data';
    });
}

My TDD approach, particularly for legacy system rewrites:

1. Write tests that mirror existing functionality
2. Follow Red-Green-Refactor cycle
3. Start with simple test cases
4. Gradually add complexity
5. Focus on business requirements
6. Maintain test documentation

Process:

// 1. Write failing test
public function test_legacy_data_migration()
{
    $legacyData = $this->getLegacyData();
    $migrationService = new DataMigrationService();
    
    $result = $migrationService->migrate($legacyData);
    
    $this->assertEquals(
        $this->getExpectedStructure(),
        $result->getStructure()
    );
}

// 2. Implement functionality
// 3. Refactor while keeping tests green

To maintain high test coverage:

1. Use PHPUnit's code coverage reports
2. Set minimum coverage thresholds in CI/CD pipeline
3. Focus on critical business logic paths
4. Implement both unit and feature tests
5. Use mutation testing tools like Infection
6. Regular code review with coverage analysis

Configuration example:

<phpunit>
    <coverage>
        <include>
            <directory suffix=".php">src/</directory>
        </include>
        <report>
            <html outputDirectory="tests/coverage"/>
            <clover outputFile="tests/coverage.xml"/>
        </report>
    </coverage>
</phpunit>

For testing complex database interactions:

1. Use Laravel's DatabaseTransactions trait
2. Create specific test databases
3. Implement database seeders for test data
4. Use factories for complex data structures
5. Test database triggers and stored procedures
6. Verify data integrity after migrations

Example:

public function test_complex_transaction()
{
    // Arrange
    $this->seed(TestDatabaseSeeder::class);
    
    // Act
    $result = DB::transaction(function() {
        $user = User::factory()->create();
        $order = Order::factory()
            ->for($user)
            ->has(OrderItem::factory()->count(3))
            ->create();
            
        return $this->orderService->process($order);
    });
    
    // Assert
    $this->assertDatabaseHas('orders', [
        'id' => $order->id,
        'status' => 'processed'
    ]);
    $this->assertDatabaseCount('order_items', 3);
}