Behavior and Examples in WordPress: Specify Before You Code

An AI agent writes a WordPress function in seconds. It cannot know what that function should do for your users. That part is yours, and in Behavior-Driven Development (BDD) it comes first: before the test, before the code.

This is the first of three BDD principles on 4wp.dev:

1. Behavior — what the user sees, with examples and edge cases (this page).
2. Driven — Given / When / Then scenarios that lead the work.
3. Development — scenario → test → code → green.

👉 Overview: Behavior-Driven Development for WordPress

Behavior: what the user sees, not how the code works

A behavior is a rule a user can check without reading the code. “We use mb_substr” is not a behavior. “A long post is cut to 300 characters and ends with …” is.

Our real case is 4WP Social, the 4wp.dev plugin that publishes WordPress posts and videos to social platforms. Every platform has its own limits, and each limit is a behavior. For Bluesky, which allows 300 characters per post:

• Text longer than 300 characters is cut and ends with ….
• Tags become hashtags only while they still fit.
• #123 and a#b are not tags.

Three lines. A client can read them, QA can check them, and an AI agent can implement them. Nobody needs to know which PHP function does the cutting.

Examples: a rule becomes clear with real input and real output

“Tags become hashtags while they fit” still leaves questions. What if the tag is already in the text? What about a tag with a space? A concrete example answers them:

description: 'Demo #WordPress'
tags:        ['WordPress', 'FAQ schema']

Bluesky text:
Demo #WordPress

#FAQschema

From one example we learn three decisions:

• #WordPress is already in the text, so it is not added twice.
• FAQ schema becomes #FAQschema: spaces are removed.
• Hashtags go after an empty line.

Write examples with real values, not foo and bar. A real value is something the user will actually type.

Edge cases are behavior too

Most bugs live at the edges. In BDD the edges are written down before the code, together with the main example:

295 characters + tag 'LongTag'   → no room, the tag is not added
400 characters                   → cut to 300, ends with "…"
'Issue #123 and a#b'             → no hashtags at all

Each line is a separate decision someone had to make. If you don’t make it, the AI agent will make it for you, silently.

The same thinking on other platforms

The Bluesky rules are not special. Every adapter in 4WP Social is described the same way, and every rule has a test with the same name. Real examples from the plugin’s test suite:

Look at the Dev.to row: a duplicate wordpress is dropped, a-b becomes ab, and only four tags survive. That is three behaviors in one example — exactly why examples beat abstract rules.

How to find behavior with a client

You don’t need special tools. Ask three questions for every feature:

1. What does the user see when it works? → the main behavior.
2. Show me one real case. → the example, with real values.
3. What if it’s empty, too long, duplicated, or in another language? → the edge cases.

Write the answers as short lines in plain language. Those lines are your specification, and the next step turns them into scenarios.

Why this matters in the AI era

Without behavior, a prompt says “add hashtags to the Bluesky post”. The agent will do it, and it will guess the limit, the duplicates and the edges. With behavior and examples, the agent has nothing to guess, and every guess it still makes is checked by a test.

AI writes the code. You define the behavior.

Next

• 👉 Given / When / Then in WordPress: Scenarios That Drive the Code
• 👉 BDD with PHPUnit in WordPress: Scenario → Test → Code → Green
• 👉 Behavior-Driven Development for WordPress (Overview)