Social Network

Level: Intermediate 30–60 min

Concepts: State

Solutions: C# | TypeScript | Python

Implement a console-based social networking application that satisfies the scenarios listed below. The application must use the console for input and output.

Users submit commands to the application. Commands always start with the user’s name.

Do not worry about handling any exceptions or invalid commands. Assume the user will always type the correct command.

Do not make it work over a network or across processes, do it all in memory assuming users are on the same terminal.

Non-existing users should be created as they post their first message. The application should not start with a predefined list of users.

Scenarios

Posting Alice can publish messages to a personal timeline. > Alice /post What a wonderfully sunny day!

Reading Bob can view Alice’s timeline. > Bob /timeline Alice

Following Charlie can subscribe to Alice’s timeline and view an aggregate list of all subscriptions. > Charlie /follow Alice

Wall Charlie can view an aggregate list of all the people he has subscribed to follow. > Charlie /wall

Note: If Charlie follows Alice and Bob he will see a time sequenced list of post from both of them on his wall. That is to say the post are displayed with the most recent at the top.

Bonus

Mentions Bob can link to Charlie in a message using ’@’. > Bob /post @Charlie what are your plans tonight?

Note: this is not a new command, just an expansion of how the /post command works. Any mentions should appear on a user’s wall even if they do not follow the user.

Direct Messages Mallory can send a private message to Alice. > Mallory /send_message Alice

Alice can view all private messages. > Alice /view_messages

Reference Walkthrough

Full C#, TypeScript, and Python implementations live at tddbuddy-reference-katas/social-network with the same eighteen scenarios across all three languages, a fluent NetworkBuilder, and a Clock collaborator so tests control timestamps deterministically.

The key design distinction is timeline vs wall: timeline shows only a user’s own posts (reverse chronological), while wall shows the user’s posts plus posts from everyone they follow (reverse chronological across all authors). Both are pure queries over the post list — no side effects.

Related reading

  • 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.
  • Test Deletion Is a Privileged Operation
    The cheapest way for an agent to make a failing test pass is to delete it. That is logical for the agent and catastrophic for the codebase. Tests are append-only by default. Deletion needs a human author, a separate commit, and a separate review.
  • The Instruction File Is Not the Discipline
    Teams that want their agent to do TDD reach for the instruction file. The TDAD paper measured this directly: adding a 'do TDD' instruction raised regressions by nearly two-thirds. Contextual test discovery cut them by seventy percent. The instruction is theatre. The codebase's test surface is the discipline.