Balanced Brackets

Level: Beginner 15–30 min

Concepts: Algorithms

Solutions: C# | TypeScript | Python

Take an input string with X opening brackets [ and Y closing brackets ], in a random order.

Determine if the generated string of brackets is balanced, that is it consists of pairs of opening/closing brackets in the correct order with no matched opening and closing pairs.

The kata has been structured to be simple, yet loosely guided. You will need to make decisions just like you were writing code for production.

The examples are not meant to guide your implementation, they are there merely to guide you.

Do not worry about input other than brackets and empty string.

Examples

(empty) ""
[] OK
[][] OK
[[]] OK
[[[][]]] OK
][ FAIL
][][ FAIL
[][]][ FAIL

Hint

Start off returning string.empty as the default condition. This will allow you properly work the red-green-refactor cycle.

Reference Walkthrough

Reference implementations in C#, TypeScript, and Python live at tddbuddy-reference-katas/balanced-brackets. This is an F1 kata — 12 scenarios for a single pure function isBalanced(input), shared across all three languages, built around a single-pass depth counter.

This kata ships in Agent Full-Bake mode at high gear: the algorithm is small enough to land as one commit per language, with a brief walkthrough noting there are no builders because the input and output are the domain. A string goes in, a boolean comes out — no aggregates to construct, no value types to introduce, no collaborators to inject. The canonical “stack-based bracket validation” framing still applies; the references note that because this kata uses only one bracket type, an int depth counter carries the same information as a stack of [ characters, and prefer the counter for that reason.

Solutions

You can find all language solutions here Balanced Brackets Solutions

Or you can select a specific language below.

Related reading

  • Katas Are Rehearsal, Not Performance
    You don't practice TDD on production code. You practice on katas and bring the muscle memory to production. The gap between knowing TDD and doing TDD is reps.
  • The Contract Test Is the Only Witness the Agent Cannot Author
    A test the agent wrote against code the same agent wrote shares the agent's blind spot: a misunderstanding in the implementation becomes a matching misunderstanding in the test, the bar goes green, and the bug ships certified. Consumer-driven contract tests are the only category where a second team publishes the assertion the first team has to satisfy. That separation of authorship is exactly what tamper-resistant test design demanded, applied at the integration seam.
  • Cohesion Is the Coverage of the Agent Era
    Agent-generated codebases pass every structural-modularity metric while fragmenting the domain concept the team was trying to encode. Coverage measured whether a line ran. Mutation score measured whether an assertion pinned behavior. Cohesion is the next axis, and it measures whether the codebase's concepts are traversable end-to-end.