Smash-QA-Framework

🔄 The Testing Pyramid

Move from heavy reliance on E2E tests to a balanced pyramid approach:

1. Unit Tests (Backend & Frontend)

Backend API Unit Tests:

// Example: Test basket creation logic
describe('Basket Service', () => {
  it('should create basket with valid VendorId', () => {
    const basket = basketService.create({ vendorId: '12345' });
    expect(basket.vendorId).toBe('12345');
    expect(basket.items).toEqual([]);
  });
  
  it('should throw error for invalid VendorId', () => {
    expect(() => basketService.create({ vendorId: null }))
      .toThrow('VendorId is required');
  });
});

Frontend Component Unit Tests:

// Example: Test CartItem component
describe('CartItem Component', () => {
  it('should display item name and price', () => {
    const item = { name: 'Classic Smash', price: 8.99 };
    render(<CartItem item={item} />);
    expect(screen.getByText('Classic Smash')).toBeInTheDocument();
    expect(screen.getByText('$8.99')).toBeInTheDocument();
  });
  
  it('should display fallback image when image URL missing', () => {
    const item = { name: 'Custom Burger', image: null };
    render(<CartItem item={item} />);
    const img = screen.getByRole('img');
    expect(img).toHaveAttribute('src', '/fallback-burger.png');
  });
});

2. Integration Tests (API Layer)

Test API endpoints with real database interactions:

// Example: Test basket API endpoints
describe('POST /api/basket', () => {
  it('should create basket and return basketId', async () => {
    const response = await request(app)
      .post('/api/basket')
      .send({ vendorId: '12345' })
      .expect(201);
    
    expect(response.body).toHaveProperty('basketId');
    expect(response.body.vendorId).toBe('12345');
  });
});

describe('POST /api/basket/products', () => {
  it('should add product to existing basket', async () => {
    const basketId = await createTestBasket();
    
    const response = await request(app)
      .post('/api/basket/products')
      .send({
        basketId,
        productId: 'burger-001',
        quantity: 1,
        options: { bun: 'classic', patty: 'double' }
      })
      .expect(200);
    
    expect(response.body.items).toHaveLength(1);
    expect(response.body.items[0].productId).toBe('burger-001');
  });
});

Key Integration Test Areas:

• ✅ /api/location/* - Location search and menu retrieval
• ✅ /api/basket/* - Basket creation, product addition, validation
• ✅ /api/basket/delivery-mode - Pickup/delivery options
• ✅ Database transactions - Ensure data consistency
• ✅ External API integrations - Google Maps, payment gateway

3. Contract Tests (API Contracts)

Use tools like Pact or Spring Cloud Contract to ensure API contracts are honored:

// Example: Consumer-driven contract test
describe('Basket API Contract', () => {
  const provider = new Pact({
    consumer: 'SmashburgerUI',
    provider: 'BasketService'
  });
  
  it('should return basket with items', async () => {
    await provider.addInteraction({
      state: 'basket exists with items',
      uponReceiving: 'a request for basket',
      withRequest: {
        method: 'GET',
        path: '/api/basket',
        query: { basketId: '12345' }
      },
      willRespondWith: {
        status: 200,
        body: {
          basketId: '12345',
          items: Matchers.eachLike({
            productId: Matchers.string('burger-001'),
            name: Matchers.string('Classic Smash'),
            price: Matchers.decimal(8.99),
            quantity: Matchers.integer(1)
          })
        }
      }
    });
    
    // Consumer test validates the contract
    const basket = await basketClient.getBasket('12345');
    expect(basket.items).toBeDefined();
  });
});

Benefits of Contract Testing:

• ✅ Prevent breaking changes to API contracts
• ✅ Enable independent deployment of services
• ✅ Fast feedback (runs in seconds)
• ✅ Clear communication between frontend and backend teams

4. E2E Tests (Critical User Journeys)

Focus only on the most important business-critical scenarios:

• ✅ Complete burger ordering flow (Create Your Own)
• ✅ Pickup order placement and confirmation
• ✅ Cart modifications and checkout
• ❌ Avoid: Testing every burger variant (covered by lower layers)
• ❌ Avoid: Testing API response formats (covered by contract tests)
• ❌ Avoid: Testing individual component rendering (covered by unit tests)

E2E Test Optimization:

• Keep tests under 30 seconds per scenario
• Use API calls for test setup (faster than UI interactions)
• Mock external dependencies when possible
• Run E2E tests only for smoke testing in CI/CD

Test Scenario

• Setup: Add 3 items to cart from test-data/mock-cart-items.json
• Items tested:
  • Double Smoked Brisket Bacon Smash® (qty: 1)
  • Chili Cheese Dog (qty: 2)
  • Large French Fries (qty: 3)
• Action: Navigate to Cart Page
• Mock Implementation: Use Playwright route interception to replace placeholder images with actual burger image

Implementation Details

// Route interception for placeholder images
await page.route('**/placeholder.e96474ea.jpg', async (route) => {
  // Fetch the actual fallback image
  const response = await page.request.get(PLACEHOLDER_IMAGE_URL);
  const body = await response.body();
  
  // Fulfill request with real image
  await route.fulfill({
    status: 200,
    contentType: 'image/png',
    body
  });
});

// Verify all cart images are visible
const cartImages = page.getByRole('img', { name: /cart item/i });
const count = await cartImages.count();
for (let i = 0; i < count; i++) {
  await expect(cartImages.nth(i)).toBeVisible();
}

Validation Points

• ✅ All cart items display images after route interception
• ✅ Placeholder image URL (placeholder.e96474ea.jpg) is intercepted
• ✅ Replacement image loaded successfully from S3
• ✅ Images are visible in DOM (toBeVisible())
• ✅ Cart layout remains consistent with images