Jakub Sobolewski

Users get value. You save time and money.

Don’t get lost in code no one asked for. Take control of what gets built.

Ready to change your workflow?

I break down how to start with Behavior-Driven Development and build features your users actually want.

How it works:
→ Start every feature as a user story, not a wish list.
→ Write specs from your users’ words.
→ Write only the code users need.
→ Automate checks along the way.

YouTube video by useR! Conference Don’t Write Code Your Users Haven’t Asked For - Jakub Sobolewski

Building code gets easier every day with AI. Building code that truly matters to users remains the real challenge.

At @user-conf.bsky.social virtual, I’m sharing how to ship only what matters.

See it here: youtu.be/e4H28G2J05U?...

#rstats #opensource

Great point.

1. APIs are versioned: you track the API version (or version of a package that wraps an API). Your contracts should be safe until you upgrade to new version.
2. Schedule a test run that checks if real APIs still return the shapes you expect. Run it periodically for extra safety.

🔁 Result:

Fast tests ✅
Reliable tests ✅
Cheap tests ✅
Better dev experience ✅

Here's the approach:

1. Abstract the dependency with an interface
2. Use fakes or mocks in tests
3. Test your code's behavior *against* the fake
4. Plug in the real dependency only in production

✅ Test only the code you own.

How? Simulate the external system in tests. You don’t need the real thing.

🚫 Why you shouldn't test external dependencies directly:

🐢 Slow (waiting for responses)
🎲 Flaky (unreliable availability/results)
💸 Expensive (API costs add up)

Or worse, tests don’t get written at all.

R Tests Gallery Learn how to effectively test in R and use tests to drive your development process.

🧪 New pattern in the R Tests Gallery: Testing code that uses LLMs, APIs, or databases

External systems power our code, LLMs, APIs, DBs, libraries, but they don’t need to be in our tests.

Check it out 👉 jakubsobolewski.com/r-tests-gall...

#rstats #opensource

Ask AI to draft specs, review them, then refine.
Repeat in minutes what might take days by hand.

Your specs become abstract, clear, and future-proof—no matter how the app evolves.

Give it a go. Cut through legacy fog with AI-powered BDD.

How to Write Cucumber Specifications the Right Way: From App Description to Scenarios Adding Cucumber specifications to an existing application? Learn how to write Gherkin scenarios that focus on user behavior, not implementation details. Use AI to iterate faster.

Looks simple but hides complexity. How to write tests that capture what happens without leaking how?

Check this post to see how to use AI to iterate on writing specifications faster: jakubsobolewski.com/blog/ai-assi...

Imagine this workflow:

👉 Start on a “Data” page with steps: Upload → Filtering → Mapping → Preview
👉 User uploads or picks a default dataset, then moves through steps
👉 Submit variable mappings → data preview appears
👉 “Visualization” unlocks to view plots

𝗪𝗮𝗻𝘁 𝘁𝗼 𝘄𝗿𝗶𝘁𝗲 𝘀𝗽𝗲𝗰𝘀 𝗳𝗼𝗿 𝗮𝗻 𝗲𝘅𝗶𝘀𝘁𝗶𝗻𝗴 𝗮𝗽𝗽? 𝗟𝗲𝘁 𝗔𝗜 𝗵𝗲𝗹𝗽 𝘆𝗼𝘂 𝗶𝘁𝗲𝗿𝗮𝘁𝗲 𝗳𝗮𝘀𝘁𝗲𝗿.

Writing specs after the fact gets messy fast. You’re tempted to mention buttons, screens, and other UI stuff, but that only locks you into one way the app works.

#rstats #opensource

The latest issue of @rweekly is now live!

https://rweekly.org/2025-W31.html

Highlights:
📊 Copy the Pros: How to Recreate this NYTimes Chart in R by @MrPecners
⏩ Speed Testing Code: Three Levels by @kellybodwin
🧪 Testing your Plumber APIs from R by @jakub-sobolewski.bsky.social

As always […]

🔔 Follow me or subscribe for updates as new examples land.
🤔 Have a specific case you want covered? Leave a comment or submit a request, let's build something great, together!

What You’ll Find

→ A growing collection of focused R test examples
→ Step-by-step breakdowns showing what to do and why it works
→ Real code ready to drop into your project with confidence

So far, there’s only one example, but many more are on the way! 🚀

As The R Tests Gallery grows, I hope it becomes a reliable source for test examples, techniques, and practical practices in live code.

The patterns featured come straight from real projects I’ve worked on, if they helped me, maybe they’ll help you too!

Your legacy Shiny app doesn't have to stay legacy forever.

Want to learn more about testing strategies for R? Check out my packages and resources for comprehensive testing approaches.

jakubsobolewski.com/blog

3️⃣ Refactor and Unit Test

Now you have a safety net. Start refactoring the code base into smaller, testable pieces. The acceptance tests will catch any regressions while you improve the code structure.

2️⃣ Create Acceptance Tests

With the behavior documented, make it executable with Cucumber.

To implement the steps you can use:

→ shinytest2
→ Playwright
→ or Cypress

There's a Cucumber implementation available to execute your specifications whether your steps are written in R or JavaScript.

Format specifications with Given, When, Then syntax to describe preconditions, actions and outcomes.

This creates living documentation that both technical and non-technical stakeholders can understand and validate.

Write it down.

Don't mix user interface with behavior. Be precise, but abstract enough so that those behaviors are true when the implementation changes. Instead of saying "click a button", try to phrase it as "do something".

Stay focused on the business goal.

1️⃣ Document Current Behavior

Work with previous maintainers and users to understand what the app should do.

Don't assume you know everything. Ask questions like:

→ What happens when users click this button?
→ How should the app respond to different inputs?

Your legacy Shiny app needs a makeover, but jumping straight into refactoring is like repainting a room with furniture still inside. Things will get messy.

The safest approach? Write acceptance tests first.

#rstats #rshiny #tests #testing #opensource

Issue 2025-W28 Highlights It's been far too long since our last episode of R Weekly Highlights, but we are finally back with episode 207! In this episode we learn about novel ways…

Episode 207 of R Weekly Highlights is out! serve.podhome.fm/episodepage/...
🛠️ Generating Quarto syntax (Danielle Navarro)
🤔 Behavior-Driven Development @jakub-sobolewski.bsky.social
🔍 Dive()ing into the Hunt @milesmcbain.bsky.social

h/t @mike-thomas.bsky.social & @rbyryo.bsky.social 🙏

#RStats

Every failing or awkward test is feedback.

Let your tests guide you toward modular, decoupled, focused code.

3️⃣ Tests can warn you when your code does too much.

If a single test checks too many things, has lots of assertions, or uses “and” in its title, your code probably lacks separation of concerns.

Clean code means each part, and each test has a focused job.

2️⃣ Tests can show if your code is tightly coupled.

If testing requires an elaborate setup or stubbing lots of internal parts, your code is likely tightly coupled.

When tests expose implementation details, it’s a warning sign: your code’s parts depend on each other too much.

1️⃣ Tests can reveal if your code isn’t modular.

If you struggle to run code in tests, needing to pass tons of arguments, set up global state, write files, or mock everything, your code probably isn’t modular.

Modular code is easy to use in any context, not just production.

3 Things Tests Reveal About Your Code

Ever wondered what your tests are really telling you about your code?
Tests aren’t just safety nets—they’re feedback loops on your design.

#rstats #tests