Connectors are a large part of qbash, and each one has to keep working after the third-party API behind it changes. Anything you build and publish yourself, whether that is a Task behind an API endpoint or a tool on an MCP server, needs the same coverage. This is how most of the team tests those now, using the LinkedIn integration I am about to ship as the example.
What's covered
- Attaching the integration to a new code Task before writing the prompt
- The prompt, and why the builder can plan tests for tools nobody listed in it
- How the generated script splits the tests by scope
- Reading the live log and the final report, including which failures were already known
Attach the integration first
The setup is a new code Task with the LinkedIn integration attached in the Tools panel. The builder reads whatever is attached, so it sees every tool the integration exposes, plus the documentation behind each one that says what it should do. Then the prompt:
I want you to build a task that completely tests all available tools for the LinkedIn integration. This test must be completely self-healing, and leave no trace, record all responses, and output a report at the end.
That is the entire prompt. Recent builder updates cut down the number of turns it takes, and this one came back close to right on the first pass.
What the builder wrote
The script groups the tests into seven phases:
- Read-only member lookups
- Read-only organization lookups, from follower counts to post analytics
- The post lifecycle, which creates a post, updates it, reacts, comments, reads the replies, then deletes the comment and the post
- Media uploads, ending with an image post that is deleted straight away
- An article post
- The same lifecycle for a post authored by the organization
- A public lookup of an organization by vanity name
Each phase lists its cleanup next to its calls. The read-only phases need none, and every resource the others create is deleted inside the same phase, which is how the script meets "leave no trace". "Self-healing" came out as every call wrapped in try/except, so one failure does not block the tests after it, and as dependent tests being skipped with a reason when a prerequisite fails.
The run
The log ticks over live, naming each phase and recording each pass and failure. Each test is an integration call, a direct API request with no model in the loop, so the run spends no AI tokens. It still checks that each tool, as defined and loaded, works when called, which is what an agent depends on.
The report at the end is a LinkedIn Integration Test Report with 53 tests: 46 passed, five failed, and two were skipped, a 90.2% pass rate once skips are left out. get_video_analytics failed with no video asset found, because the video upload had been skipped for want of a real video file. get_comment_replies returned a 400 syntax exception in its path variables, one of a couple of bugs I was already tracking.
The Task can be run by hand whenever you want to check the connector, or put on a schedule so the suite runs on its own.
Video transcript
Hey guys, Mitch from qbash here. Today, I want to take you through one of the ways that I'm using tasks all of the time. Most of the team is using tasks like this all the time. And that is very easily building self-healing tests for things like integrations or tools or things that you build. So, a big part of the platform, obviously, is our connectors or our integrations.
These are native tools that we build that allow you to uh use qbash with third-party pieces of software. And so, we want to make sure that they work all of the time. They're always working. We want to understand when things aren't working, obviously. qbash as a platform also kind of allows you to build your own tools, whether those be tasks that you deploy to an API endpoint or deploy in an MCP server, whatever it might be.
You need a way to test them, right? So, the example that I'm going to do today is I'm going to build a very quick self-healing complete test for a LinkedIn integration that I'm rolling out soon. For example, I can come in here into tasks. New task. This is going to be a code task.
I'm going to almost immediately come in here and attach the integration and then come in and let's just use the builder to do this. There's been a bunch of updates and upgrades to the builder recently. So, if you're using it, you might notice improved speed, fewer turns, all of that kind of stuff. It's really, really responsive and it's kind of nailing all of my asks on almost on one shot. Okay, so what do I want to do?
I want you to build a task that completely tests all available tools for the LinkedIn integration. This test must be completely self-healing, and leave no trace, record all responses, and output a report at the end. That's literally it. Because it's a build agent, and we've given it access to that integration rather, it knows all the tools that are there, and there's documentation in the back end that kind of says what the tool should be able to do. And so, it can go ahead and build out basically this long script that is going to go through one by one and test all of the tools, and record what is returned, and yeah, we'll see what that looks like.
Okay, and we can see the streaming in now. So, it has split it up by scopes. So, you have the read-only member stuff, the read-only organization stuff. You have a post lifecycle kind of set of set of actions, so creating a post, updating it, reacting, all of that. Uploading media articles posts from an organization, for example, and then public lookups.
It's fully self-healing, gracefully skips if something doesn't work. Save this, and we will run this here, so we can watch the logs tick over in real time. So, you can see here that it's logging what phase that it's in. It's, you know, logging what passes and what fails, and it is just executing tool calls. These are just API calls, and so, there's no token usage here, but you are verifying that, you know, the tool as it is created and loaded will work for an agent should you give that to an agent.
So, if we open the chat, we'll see here that there were 53 tests that were done, 46 of them worked, five of them failed, and two of them skipped. Failures, video analytics, no video asset found. I think that's going to be because, yep, it skipped uploading a video because we didn't have a real video file. Get comment replies, 400 syntax exception in path variables. These are actually a couple of bugs that I'm already tracking.
So, anyway, I hope that was a quick and informative video about how we are putting together tests really, really quickly. This is something that you can run on a schedule or you can trigger manually. Okay. Thanks for watching.