TDD and BDD for SDET Interviews 2026 — Red-Green-Refactor Cycle, TDD vs BDD vs ATDD Methodology Deep-Dive, Test Doubles and Mocking Strategies, TDD for Test Automation (Testing the Tests), When NOT to Use TDD (The Interview Curveball), TDD with Playwright and Selenium (Can You Test-First for UI?), and BDD/Cucumber Quick Recap with Real Panel Questions

You're fifteen minutes into the SDET interview. The panel has warmed up — asked about your current role, your tech stack, a bit about your CI/CD pipeline. You're comfortable. Then the technical lead leans forward: "You mentioned you practise TDD. Walk me through a time when you deliberately chose NOT to use TDD — and what drove that decision." Your brain freezes. You've been doing TDD for two years. You've never thought about not doing it. You mumble something about time pressure, about legacy codebases, about trade-offs you've never actually had to make. The lead nods, but you can see them making a note — and you know it's not the good kind.

This is the methodology curveball. In 2026, SDET interview panels have stopped asking "what is TDD" and started asking questions that separate engineers who think about methodology from those who simply follow it. They want to know whether you understand TDD deeply enough to know its limits. Whether you can discuss BDD as a collaboration practice, not just a Cucumber tutorial. Whether you've encountered the situations where test-first breaks down — and what you did about it. Whether you use test doubles strategically or just mock everything because the blog post told you to. This guide covers every methodology question that modern SDET panels are probing — from the red-green-refactor cycle at architectural depth, to the TDD-vs-BDD-vs-ATDD comparison that reveals whether you think in trade-offs, to the honest, experience-backed answers on when TDD works, when it doesn't, and what to do instead. Complement this with our deep-dive on BDD and Cucumber Interview Questions 2026 for the full Cucumber and Gherkin side, our Test Automation Framework Design Interview guide for the architecture decisions that methodology ultimately serves, and our Playwright Interview Questions 2026 for the UI automation tool where TDD's applicability gets genuinely interesting. The SDET Interview Coach iOS app includes dedicated TDD and methodology mock interview rounds — with AI-scored questions covering red-green-refactor, test doubles strategy, TDD-vs-BDD trade-offs, and the "when not to use TDD" curveball at five seniority levels.

TDD vs BDD vs ATDD — The Methodology Map Every Panel Expects You to Navigate

There's a question that appears in nearly every methodology discussion in SDET interviews, phrased differently depending on the panel but always testing the same thing: do you understand the purpose of each approach, or do you just use whichever one your team adopted before you arrived? The question is some variation of: "Explain the difference between TDD, BDD, and ATDD — and when you'd pick each." Here's what a high-scoring answer covers — and what separates an engineer who's thought about methodology from one who's only executed it.

The follow-up that panels use to test depth: "Can you use all three on the same project, or do you pick one?" The strong answer: "They're complementary, not competing. On a typical project, I'd use BDD scenarios (written collaboratively with the product owner in Gherkin) to define the critical user journeys — maybe 10-15 high-value scenarios. ATDD acceptance tests define the remaining acceptance criteria at the API or integration level — tests that define 'done' without the Gherkin layer. TDD drives the unit-level implementation of every component that makes those acceptance tests pass — potentially hundreds or thousands of unit tests. BDD validates the user sees the right thing. ATDD validates the system does the right thing. TDD validates each component is built the right way. Together they form a layered verification strategy — not a pick-one menu."

The Red-Green-Refactor Cycle — Beyond the Mantra, Into the Engineering

Every candidate knows the three words: Red, Green, Refactor. But in 2026, panels aren't testing whether you can recite them — they're testing whether you've internalised enough to know what each phase really means, what traps hide in each, and what happens when the cycle breaks. Here's what interviewers are actually probing at each stage:

// TDD in Practice: Red-Green-Refactor for a ShoppingBasket total calculation

// ─── RED: Write a failing test first ───
// Test: should return zero for an empty basket

describe('ShoppingBasket', () => {
  it('should return zero total for an empty basket', () => {
    const basket = new ShoppingBasket();
    expect(basket.getTotal()).toBe(0);
  });
});

// ─── GREEN: Minimum code to pass ───

class ShoppingBasket {
  getTotal(): number {
    return 0; // Hardcoded — but the test passes!
  }
}

// ─── RED: Next test drives generalisation ───
// Test: should return item price for a basket with one item

it('should return item price for a basket with one item', () => {
  const basket = new ShoppingBasket();
  basket.addItem({ name: 'Widget', price: 9.99 });
  expect(basket.getTotal()).toBe(9.99);
});

// ─── GREEN: Now generalise — the test forces it ───

class ShoppingBasket {
  private items: Array<{ name: string; price: number }> = [];

  addItem(item: { name: string; price: number }): void {
    this.items.push(item);
  }

  getTotal(): number {
    return this.items.reduce((sum, item) => sum + item.price, 0);
  }
}

// ─── REFACTOR: Extract magic constant, improve naming ───

const EMPTY_TOTAL = 0;

class ShoppingBasket {
  private items: Item[] = [];

  addItem(item: Item): void {
    this.items.push(item);
  }

  getTotal(): number {
    if (this.items.length === 0) return EMPTY_TOTAL;
    return this.items.reduce((sum, item) => sum + item.price, 0);
  }
}

// The key insight: every line of production code was demanded by a failing test.
// The refactor improved readability without changing behaviour.
// Tests stay green through every refactor — that's the safety net.

// ─── RED: Next increment — apply a discount ───

it('should apply a 10% discount when promo code is valid', () => {
  const basket = new ShoppingBasket();
  basket.addItem({ name: 'Widget', price: 100.00 });
  basket.applyPromoCode('SAVE10');
  expect(basket.getTotal()).toBe(90.00);
});

// This cycle continues — each test drives one behaviour,
// each implementation is the minimum to pass,
// each refactor keeps the design clean.

"When Have You NOT Used TDD?" — The 2026 Methodology Curveball and How to Answer It

This is the question that separates TDD practitioners from TDD dogmatists — and it's appearing in more SDET interviews in 2026 than ever before. Panels are tired of candidates who recite "TDD is always the answer" without having encountered the real-world situations where test-first doesn't work or isn't worth the cost. Here's how to answer this question with the nuance that panels are listening for:

The meta-answer that panels reward: "TDD is a tool, not a religion. I use it when it adds net value — which is most of the time for business logic, service layers, and algorithmic code — and I'm explicit about why I'm not using it when the situation calls for a different approach. Dogmatic 'always TDD' is as unconvincing as 'never TDD.' The skill is knowing the difference." This demonstrates judgement, pragmatism, and real-world experience — exactly what senior panels are hiring for.

Test Doubles in TDD — Mocks, Stubs, Fakes, Spies, and Dummies Explained with Interview-Ready Precision

If TDD is the engine, test doubles are the transmission — they're how you isolate the code under test from its dependencies so you can test one thing at a time. In 2026, panels aren't asking "what's a mock?" — they're asking when you'd use a stub vs a mock, why over-mocking is a design smell, and how test doubles in TDD differ from test doubles in traditional test-after development. Here's the complete taxonomy, with the nuance that scores:

// Test Doubles in TDD: A concrete example in TypeScript with Jest

// ─── The System Under Test: OrderService ───

class OrderService {
  constructor(
    private orderRepo: IOrderRepository,    // Query: stub this
    private paymentGateway: IPaymentGateway, // Command: mock this
    private emailService: IEmailService,     // Command: mock this
    private logger: ILogger                  // Usually a dummy
  ) {}

  async placeOrder(order: Order): Promise<OrderResult> {
    // Query existing orders (stub the repo)
    const existing = await this.orderRepo.findByCustomerId(order.customerId);
    
    // Business logic: check duplicate
    if (existing.some(o => o.productId === order.productId && o.isRecent())) {
      return { success: false, reason: 'DUPLICATE_ORDER' };
    }

    // Command: charge payment (mock the gateway — side effect matters)
    const payment = await this.paymentGateway.charge(order.amount, order.paymentMethod);
    
    if (!payment.success) {
      return { success: false, reason: 'PAYMENT_FAILED' };
    }

    // Command: send confirmation (mock the email — side effect matters)
    await this.emailService.sendOrderConfirmation(order, payment.transactionId);

    // Log — use a dummy in most tests
    this.logger.info('Order placed', { orderId: order.id });

    return { success: true, orderId: order.id };
  }
}

// ─── TDD Test: Stubs for queries, Mocks for commands, Dummy for logger ───

describe('OrderService.placeOrder', () => {
  it('should reject duplicate orders for the same product within 24 hours', async () => {
    // Arrange
    const orderRepoStub = {
      findByCustomerId: jest.fn().mockResolvedValue([
        { productId: 'P123', createdAt: new Date() } // Recent duplicate
      ])
    };
    
    // Payment and email are mocks — we expect them to NOT be called
    const paymentMock = { charge: jest.fn() };
    const emailMock = { sendOrderConfirmation: jest.fn() };
    
    // Logger is a dummy — not used in assertions
    const loggerDummy = { info: jest.fn(), error: jest.fn(), warn: jest.fn() };

    const service = new OrderService(
      orderRepoStub as any,
      paymentMock as any,
      emailMock as any,
      loggerDummy
    );

    // Act
    const result = await service.placeOrder({
      id: 'ORD-002', customerId: 'C1', productId: 'P123',
      amount: 49.99, paymentMethod: 'card'
    });

    // Assert: state verification (stub) + interaction verification (mocks)
    expect(result.success).toBe(false);
    expect(result.reason).toBe('DUPLICATE_ORDER');
    
    // Verify side-effect commands were NOT called (important!)
    expect(paymentMock.charge).not.toHaveBeenCalled();
    expect(emailMock.sendOrderConfirmation).not.toHaveBeenCalled();
  });
});

// The pattern: stub queries, mock commands, dummy everything else.
// This test is resilient to refactoring — change the repo call pattern
// and the test still works because we only assert on outcomes + side effects.

TDD for Test Automation — How to Test Your Tests (And Why Panels Ask This)

This is the methodology question that catches even experienced SDETs off guard: "Do you apply TDD to your test automation code? How do you test your tests?" It sounds meta — and it is. But it's a legitimate question that reveals whether you treat test automation as engineering or as scripting. Here's how to answer it with the depth that panels reward:

The panel's real question: When they ask "do you test your tests?" they're probing whether you see test automation as software engineering or as scripting. The engineer writes testable test code. The scripter writes scripts and hopes. Your answer should make clear which one you are.

Can You Do TDD for UI Automation? — The Playwright and Selenium Test-First Question

This is one of the most debated methodology questions in test automation — and it comes up in SDET interviews because it tests whether you can think critically about methodology rather than applying it dogmatically. "Do you do TDD with Playwright or Selenium? Can you write a UI test before the UI exists?" Here's the honest, experience-backed answer that panels reward:

// TDD for Component-Level UI Testing (works well)
// vs End-to-End Playwright Testing (test-after, TDD-principled)

// ─── COMPONENT TDD: LoginForm (React + Testing Library) ───
// Fast, isolated, drives component design

// RED: Write the test first
describe('LoginForm', () => {
  it('should show validation error when email is empty on submit', async () => {
    render(<LoginForm onSubmit={jest.fn()} />);
    
    // Submit with empty fields
    await userEvent.click(screen.getByRole('button', { name: /log in/i }));
    
    // Assert validation message appears
    expect(screen.getByText('Email is required')).toBeInTheDocument();
    expect(screen.getByRole('textbox', { name: /email/i }))
      .toHaveAttribute('aria-invalid', 'true');
  });
});

// GREEN: Implement minimum validation
// REFACTOR: Extract validation rules, improve error messages

// ─── E2E TEST: Checkout Flow (Playwright — test-after, TDD-principled) ───
// The UI exists. The test validates the user journey.

test('should complete checkout with valid payment', async ({ page }) => {
  // Arrange: Navigate and add item to basket (precondition)
  await page.goto('/products');
  await page.click('[data-testid="add-to-basket-001"]');
  
  // Act: Complete checkout
  await page.click('[data-testid="checkout-button"]');
  await page.fill('[data-testid="card-number"]', '4242424242424242');
  await page.fill('[data-testid="card-expiry"]', '12/28');
  await page.fill('[data-testid="card-cvc"]', '123');
  await page.click('[data-testid="pay-button"]');
  
  // Assert: Confirmation page appears
  await expect(page.locator('[data-testid="confirmation"]'))
    .toContainText('Order confirmed');
  await expect(page.locator('[data-testid="order-number"]'))
    .toBeVisible();
});

// The TDD principle: one user journey per test.
// The pragmatic reality: the UI existed before the test.
// Both are valid. Knowing which applies where is the skill.

BDD and Cucumber — A Concise Recap for Methodology-Focused Interviews

Since BDD invariably comes up alongside TDD in methodology discussions, here's the essential recap every SDET should have ready — focused on how BDD relates to and differs from TDD, rather than the full Cucumber deep-dive (which we cover in our dedicated BDD and Cucumber Interview Questions 2026 guide).

6 Common TDD and Methodology Mistakes That Cost SDET Candidates Offers

After watching hundreds of candidates navigate methodology questions, these are the specific mistakes that cause interviewers to lean back and mentally move on to the next candidate. They're not knowledge gaps — they're articulation gaps. You might know the material, but if you present it the wrong way, the panel won't hear it.

What a Real TDD and Methodology SDET Interview Looks Like — Timed Breakdown

Drawing from panels conducted across UK government and enterprise environments, here's how TDD and methodology questions typically appear in a 60-minute SDET interview — and what the panel is evaluating at each stage:

Methodology Questions Are Strategy Questions — Treat Them That Way

TDD, BDD, and ATDD aren't testing techniques. They're engineering strategies — decisions about how your team builds software, verifies correctness, and communicates about behaviour. In 2026, panels are probing methodology not because they want you to recite the Red-Green-Refactor mantra, but because they want to know whether you'll make good engineering decisions when the context is ambiguous and the trade-offs are real.

The candidate who can discuss TDD's limits alongside its strengths, who knows when to stub and when to mock, who understands that BDD is a collaboration practice with a testing tool attached — not the other way around — that candidate demonstrates the kind of engineering judgement that scales across teams, projects, and seniority levels. Methodology isn't dogma. It's decision-making under uncertainty. Show the panel you can make those decisions, and you've shown them you're ready for the senior seat.

For structured preparation, SDET Interview Coach includes a dedicated TDD and Methodology topic area with AI-scored questions covering the red-green-refactor cycle, test doubles classification (dummies, stubs, mocks, fakes, spies), TDD vs BDD vs ATDD trade-offs, TDD for test automation code, and the "when not to use TDD" curveball — calibrated across five seniority levels. Pair it with our BDD and Cucumber Interview Questions 2026 guide for the Gherkin and step definition side, and our Test Automation Framework Design Interview guide for the architectural patterns that methodology ultimately serves.