Q40 of 40 · Karate

How do you onboard a team that's never worked with a BDD framework before?

KarateLeadkarateleadershiponboardingmentoringbdd

Short answer

Short answer: Start with a working example suite so the team can run and modify before they write. Pair on the first feature file — Given/When/Then transfers from plain language if they've never done BDD. Teach * def and * match first; introduce parallel runner, mocks, Gatling, and custom hooks only after the team has shipped 20+ passing scenarios.

Detail

Week 1 — run before write: provision a working Karate suite with 5 example features covering the most common endpoints. The team's first task: run it, break it deliberately, and read the HTML report. Understanding the report output before writing tests builds intuition for what a good test looks like.

Week 2 — first feature file: pair-program the first real test scenario together. Focus on:

  • Feature/Background/Scenario structure
  • The url, path, method, status keywords (the HTTP verbs of Karate)
  • * def and * match for simple assertions
  • The difference between match == and match contains

Week 3 — data and reuse: call read for the login helper, extracting setup into helpers/, * def capturing response fields for use in follow-up requests.

Week 4 — parallel and CI: the JUnit runner, karate-config.js for environments, publishing the HTML report in the pipeline.

What to defer: WebSockets, Karate Gatling, RuntimeHook, karate.callSingle, advanced JS patterns — introduce these when the team hits a real problem that requires them, not as curriculum topics.

Code review guidelines for the first month: check for hard-coded URLs (should use config variables), missing teardown, overly strict match == where contains is appropriate, and re-fetching tokens on every scenario (should use callSingle or callonce).

// EXAMPLE

onboarding-exercise.feature

# Week 2 onboarding exercise: write this feature from scratch
# (trainer shows the pattern once, team implements the next 3)

Feature: Product catalogue — onboarding exercise

  Background:
    * url 'https://api.example.com'
    # Task 1: add the auth header here using the token from karate-config.js
    # * header Authorization = ...

  Scenario: Get product by ID returns correct name
    # Task 2: fill in the path and method
    Given path ...
    When  method ...
    # Task 3: assert status and product name
    Then  status ...
    And   match response.name == ...

  Scenario: Get missing product returns 404
    # Task 4: what path triggers a 404?
    # Task 5: should the response body match anything?

  # After review: introduce match with # markers
  # After review: introduce call read for auth token
  # Week 3: extract auth to Background, extract product lookup to a helper

// WHAT INTERVIEWERS LOOK FOR

Progressive curriculum (run → read → write → refactor), paired learning for the first scenario, concrete deferral of advanced topics, and code review criteria for the first month. This reflects experience building team capability, not just personal Karate expertise.

// COMMON PITFALL

Teaching karate-config.js, parallel runner, karate.callSingle, and RuntimeHook in week 1. Engineers leave the session unable to write a basic feature file without referencing the full framework setup. Start with one scenario that works; add layers when fundamentals are solid.

// Related questions

How would you justify Karate's BDD-style DSL to engineers used to writing tests in Java/JS code?

Karate

Tell me about a time you mentored someone and what you learned from it.

Behavioural

How do you structure a Karate project (folders, naming, configuration files)?

Karate