Integrating Tessl into Test-Driven Development workflows

By default, the Tessl framework favours fast cycles of spec change - code generation - manual testing. This approach allows you to focus on rapid development of new or updated capabilities first and foremost. Once you are happy that your core functionality has been captured, you can fine-tune the application with a more rigorous set of tests. This does require more time, however, as it demands a greater investment in test and fix cycles. For more information about how to do this, read our Adding tests to specs common workflow.

Test-Driven Development (TDD), however, is an approach whereby the tests are built first and fail until the required development code has been written to make those tests pass. In spec-driven development, this is done by creating your spec with your tests upfront and then testing the implementation against the tests at every stage of the build.

Let’s look at an example and share how we could change our request to the agent and CLI.

First, I’ll create a spec that sums basic dice notation. For example, 2d6 would be the sum of two rolls of a six-sided dice. This could be anything from 2 to 12.

This process took me through the bootstrapping process and created the following spec:

# Dice Notation Parser and Calculator

Parses basic dice notation and calculates the sum of simulated dice rolls.

## Target

[@generate](../src/dice-notation.js)

## Capabilities

### Parse dice notation

Parses strings in the format "NdS" where N is the number of dice and S is the number of sides per die.
- Handles basic notation like "1d6", "2d8", "3d10"
- Extracts number of dice and sides from the notation string
- Validates that the notation format is correct

### Simulate dice rolls

Generates random numbers to simulate rolling the specified dice.
- Each die roll generates a random number between 1 and the number of sides (inclusive)
- Rolls the specified number of dice
- Uses appropriate randomization for fair dice simulation

### Calculate sum

Returns the total sum of all dice rolls.
- Adds up all individual dice roll results
- Returns a single numeric sum

## API

javascript { .api }
/**
 * Parses dice notation and returns the sum of simulated dice rolls
 * @param {string} notation - Dice notation in format "NdS" (e.g., "2d6", "1d20")
 * @returns {number} Sum of all dice rolls
 * @throws {Error} If notation format is invalid
 */
 
function rollDice(notation) {
  // Implementation will be generated
}

module.exports = { rollDice };

Notice the capabilities don’t have any tests associated with them. I need to perform three tasks from here:

1. Add tests to the spec file

2. Generate the test files

3. Generate the code

I’ll ask my agent to edit the spec first to add tests, then generate the code files from the spec, and finally generate the code. From this point on, the `tessl build` command will always run my tests as part of the process.

After the spec has been edited, my capabilities in the spec have been updated as follows:

### Handle invalid input

Validates input format and provides appropriate error handling.

- Throws error for empty string [@test](../tests/dice-notation.test.js)
- Throws error for invalid format [@test](../tests/dice-notation.test.js)
- Throws error for malformed notation [@test](../tests/dice-notation.test.js)

### Return results within expected ranges

Ensures dice roll results fall within mathematically correct bounds.

- "1d6" returns sum between 1 and 6 [@test](../tests/dice-notation.test.js)
- "2d6" returns sum between 2 and 12 [@test](../tests/dice-notation.test.js)
- "3d4" returns sum between 3 and 12 [@test](../tests/dice-notation.test.js)
- "1d20" returns sum between 1 and 20 [@test](../tests/dice-notation.test.js)

The next step is for Tessl to generate the tests, which it does via the build-tests tool. This generates the dice-notation.test.js test file mentioned in the spec.

Finally, the code is built and the tests are successfully run:

Subsequent Tessl builds will run the tests if you pass a test command, such as testCommand: "npm test" and this will then adhere to the test-drive development workflows going forward.