nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

[Open beta] Introducing Tests in Bitbucket Pipelines

Dan Hom

Hi Bitbucket community!

We’re thrilled to announce that Tests is now in open beta for Bitbucket Pipelines! This new feature for Bitbucket Cloud Standard and Premium workspaces introduces a single place inside your repository to:

See the health of every test over time
Drill into detailed execution history for each test
Identify and quarantine flaky tests so they stop blocking your team
Automatically skip quarantined tests in your pipelines’s build script to keep builds fast and reliable

All from within the place you already use to review code and powered by the JUnit-style XML reports you already generate today.

What is Tests?

Once enabled, you’ll see a new Tests tab in your Bitbucket repository.

This tab includes a summaries page that aggregates data for each individual test based on its recent runs, including:

Failure rate – how often this test fails
Average duration – how long it usually takes
Variance – how much its execution time fluctuates

You can search and filter through the view to find a specific test, filter by labels, and filter by test state (such as whether the test is considered flaky or has been quarantined)

This makes it easy to spot frequently failing tests that hurt developer conference, slow tests that drag out pipelines, or unstable tests with highly variable run times.

You can also click into an individual test to see details about its execution, including:

Build – the build that ran the test
Commit – the commit associated with that run
Last executed – when it last ran
Execution duration – how long it took
Outcome – whether it passed or failed

Take back control from flaky tests

With Tests, you can classify tests as problematic, specifically as:

Flaky – unstable and needing attention
Quarantined – unreliable enough that it shouldn’t block builds right now

Behind the scenes, Bitbucket maintains a test metadata file for your repository that tracks these classifications. Your pipelines can download this file and use it to skip tests marked as 'quarantined.'

Check out the blog to see exactly how.

Try it now and share your feedback

If your Bitbucket Cloud workspace is on the Standard and Premium plan, you are automatically able to use these beta features by default.

Enable Bitbucket Pipelines for your repository (if it isn’t already).
Configure your test framework to generate JUnit-style XML reports or change the paths which are identified by the tests feature.
Open your repository and click the Tests tab.
Explore Test summaries and drill into Test executions to see your current test health.
Start marking flaky and quarantined tests to bring structure and clarity to your suite.
(Optional) Opt in to using the test metadata file in your pipeline steps so you can automatically skip quarantined tests and keep builds green and fast.

As we build out Tests, your feedback will help shape its future. Whether you have feedback, questions, or need help, this community thread is the go-to place to discuss your experience with Tests, report issues, or share ideas. Your input will directly influence the GA release and beyond, so let us know how Tests is working for you!

Comments

Yuxin Wang_lpotub

Does it support child pipeline?

Stijn Post_abp8je

We have set it all up according to the documentation (self hosted runner V4), and see a lot going right as is the junit xml is loaded well into the pipeline "Tests" tab but afterwards we see nothing going into the repo Test "Beta" tab.

Extract from build log:
Located test suite containing 4 tests, with 0 failures and 0 errors.
Located test suite containing 2 tests, with 0 failures and 0 errors.
Located test suite containing 2 tests, with 0 failures and 0 errors.
Located test suite containing 1 tests, with 0 failures and 0 errors.
Located test suite containing 6 tests, with 0 failures and 0 errors.
Located test suite containing 2 tests, with 0 failures and 0 errors.
Finished scanning for test reports. Found 1 test report files in 0 seconds.
Merged test suites, total number tests is 774, with 1 failures and 0 errors in 0 seconds.
Uploading test results
Finished uploading test results in 0 seconds.

delcom-dev___web-sporter-frontend_—_Bitbucket.png

Gabriel

Like @Stijn Post we have tests reporting success/failure in the pipeline but nothing is showing up in the new Tests (BETA) tab. Build log shows the test report getting picked up and processed.

Does the step have to run on the main development or production branches @Dan Hom? I was testing the junit changes to our repository from a feature branch to review the setup for this new capability.

Gummi A

Same here as has been described, we see test results in Pipeline tab but the new Tests tab is empty.

PasteImagDontWorkScreenshot 2026-01-29 150352.png Screenshot 2026-01-29 150500.png

Ben Ford

Same issue as people above, works in pipelines. Nothing showing in the UI.

Ben

G'day all @Yuxin Wang @Stijn Post @Gabriel @Gummi A @Ben Ford !

Welcome to the Bitbucket Cloud community! Thank you for raising these concerns

Could you please create support tickets so that we can look into the specific issues for your repositories and engage the necessary engineering teams to assist further? You'll need to enter the workspace URL for your paid workspace and select Bitbucket Cloud as the product:

https://support.atlassian.com/contact

Below is some general information that I've received from our engineering team:

In the current release there are some rules which we have added for this feature to work:1. You should be on Standard or Premium plans (I can see you are all on Premium)2. As of now the test cases in `Tests` would show up only from the default branch (e.g main or master) pipelines, the feature branches tests wouldn't show up.3. Tests executed in pipelines running Self hosted runners wouldn't show up. This support would come up in coming releases.4. The Test reports which the frameworks are generating needs to be in the Junit xml format, more on this is here: https://support.atlassian.com/bitbucket-cloud/docs/test-reporting-in-pipelines/

Please check the documentation for more details - https://support.atlassian.com/bitbucket-cloud/docs/test-reporting-in-pipelines/

Cheers!

- Ben (Bitbucket Cloud Support)

Rajkumar Singh

@Yuxin Wang Yes the tests running in the child pipelines should show up in the Tests UI as long as the pipeline is fulfilling the criterrias mentioned in this thread

Stijn Post_abp8je

Ok that clears up the doubts, except for "only from the default branch" all fine. Would be great if we could set the tests to work with another branche like "development" @Ben

Ben Ford

I agree with @Stijn Post , this should be for all branches. Or at least configurable for which branches. For me only showing it on the main branch is a little silly because if any tests failed they wouldn't get merged due to PR rules. So think it needs to change the way it is currently implemented.

Stijn Post_abp8je

Indeed having it only in main/master doesnt make sense for us in our CI/CD pipeline. I would expect to be able to have this for one selectable branche

Paulo Henrique dos Santos Eiterer

We don't use Bitbucket Pipelines, but we have our own pipeline right now, and we use the Bitbucket API to send the build status. It would be great if we could still use our own pipeline and use the API to post the JUnit-style XML reports. @Ben

Rajkumar Singh

Thanks so much for the detailed feedback, @Stijn Post @Ben Ford – this is really helpful context.

You’re right that limiting this to the default branch isn’t ideal for many CI/CD setups, especially where you’re enforcing PR rules and doing most of your validation on branches like development before anything reaches main/master.

Right now, we’ve released this version of the feature as an experiment so we can validate the core experience, learn from real usage, and iterate quickly. Branch flexibility is one areas we will be looking into as we get more feedback about the feature and improve it.

In the meantime, we’d really appreciate it if you could try the current version and share how it fits (or doesn’t fit) into your workflow:

Are there any rules or patterns you use today to decide where tests should run or be surfaced?
Highlight any other functionality that you think would be useful for your workflows?

Feel free to raise support ticket of a functionality request and we would be happy to evolve this new feature into something which is improving all the aspects related to your needs.

Rajkumar Singh

@Paulo Henrique dos Santos Eiterer

Thanks a lot for sharing this, and for already integrating with Bitbucket via the build status API – that’s super helpful context.

Right now, posting JUnit-style XML reports directly via the Bitbucket API (without using Bitbucket Pipelines) isn’t supported. The current version of test management is coupled to Pipelines so we can make sure we fully understand usage and scale before we open it up further.

That said, your workflow is exactly the kind of use case we’d like to support as we mature the feature. To do that well, we need to understand more about how you’re running tests and what “good” would look like for you:

What CI system are you using today?
How are you currently generating and storing your JUnit XML reports?
At what point in your pipeline would you ideally send those reports to Bitbucket?

If you’re open to it, we’d love to set up a short call to go deeper into your setup and requirements so we can factor this into our roadmap. If that works for you, please let us know your preferred times/time zone and we’ll reach out to schedule something.

Stijn Post_abp8je

@Rajkumar Singh Thanks for the update. We wont be testing this feature in main/master as that process just doesnt fit our CI/CD.

So until we can set the branche where to run it all from we will continue to use https://testomat.io as here we can have our e2e and unit test suite run on every PR independent of branche and get nice historic insights in test runs

Rajkumar Singh

@Stijn Post thanks for the extra context and for sharing how you’re using testomat.io today – that’s really helpful.

We’ve created a feature request to better support your use case:
https://jira.atlassian.com/browse/BCLOUD-23991

We’ll use this ticket to gather additional interest from other customers with similar CI/CD setups and will explore how we can support configuring which branch these tests should run from. I’ve linked your feedback there so it’s part of the conversation as we evaluate next steps.

Andrew Simpson

This is a good feature, but: one of the most important metrics when testing is how much of the code is actually exercised by tests, if it's trending in the right direction, how PRs affect code coverage, etc. I'd really prefer to have visualisation of code coverage data rather than detection of flaky tests with "statistical algorithms and AI agents".

If AI agents really must be jammed in somewhere, code coverage integration would allow detection of untested areas of code, which an AI agent could automatically write a test to cover.

At the very least, an update on the open code coverage feature request would be nice.

Rajkumar Singh

Thank you @Andrew Simpson for taking the time to write this up and for linking the code coverage request.

We absolutely agree that code coverage visibility is a core part of testing, and that it pairs naturally with any work we do around test reliability. We don’t have anything concrete to share yet on coverage visualisation or deeper integration with BCLOUD-15935, but this is an area we’re planning to explore in upcoming cycles – both in terms of surfacing coverage trends (per repo/branch/PR) and using that data to highlight untested areas.

Once we’ve got a clearer plan and timelines, we’ll circle back with an update

Jeff Cook_qjta2o

I look forward to being able to use this feature. Is there an eta on when this will work with self hosted runners?

I understand the idea that the tests page/dashboard would only show the default branch. However being able to compare in a PR the PR branch vs the last default branch would be extremely helpful!

What is the change in tests from the default branch?

Rajkumar Singh

Thanks @Jeff Cook for the thoughtful feedback — really glad to hear you’re looking forward to using the feature!

On self-hosted runners: support isn’t available just yet, but it’s definitely on our roadmap. In the meantime, can I ask — are you using self-hosted runners across all your repos, or do you have any repositories still running on Bitbucket Pipelines’ cloud runners? If so, it’d be great if you could try the feature there and let us know how it works for you.

Regarding PR branch vs default branch comparisons — totally agree this would be extremely valuable. We’re actively exploring support for ingesting test results from additional branches (likely starting with a limited set), and you should expect updates on this in the coming quarters.

For your last point — “What is the change in tests from the default branch?” — could you share a bit more detail on what kind of signal or comparison you’re hoping to see here? That’ll help us shape this in the right direction.

Lastly, if you’re open to it, we’d love to set up a quick call to understand your workflow, how you’d like to use this feature, and gather direct feedback on your requirements. Just let us know — happy to coordinate!

Looking forward to hearing your thoughts.

antti.peltola

This is a good addition to bitbucket. Here are a couple of things that would make it more useful for my use.

Quarantined tests: Development branches run end-to-end tests within the bitbucket jobs, but everything from staging onwards happens outside of bitbucket. It would be nice to have some sort of the api to pull the quarantined tests information outside of bitbucket, so that we could use the same data to filter our tests in staging.
Detailed execution history: It seems that we we only get the tests results from the main branch currently with no option to record test results from feature branches. Our test execution mainly happens in the feature branches so we are lacking the data from those tests.

Rajkumar Singh

Thank you @antti.peltola the thoughtful feedback — this is super helpful.

Quarantined tests / using data outside Bitbucket
We’re planning to expose this data via APIs (and potentially other integration points) so customers can pull quarantined test information out of Bitbucket and use it in downstream systems or build custom forge apps/workflows as per their needs. This is exactly the kind of use case we want to support. We should soon be having more details about this, I have created a BCLOUD ticket for this feel free to upvote or provide more details.
Detailed execution history on non‑default branches
We’re also looking into enabling test ingestion and surfacing results from non‑default branches, so you can get a more complete view of your test health across feature and release branches as well. You can follow progress on this via our public ticket here:
https://jira.atlassian.com/browse/BCLOUD-23991
This is one more item which we are actively looking into and will have something ready soon!

Stay tuned — your input is directly shaping how we evolve the Tests experience in Pipelines.

We’d also love to learn more about your workflows and how you’re managing tests today. If you’re open to it, would you be interested in a short call to walk us through your setup and share more detailed feedback on test management in Bitbucket?

antti.peltola

@Rajkumar Singh Yea, we can do a short call on this. Next week, maybe?

Rajkumar Singh

Sounds good @antti.peltola , thanks for being open to a call!

You can book a time that works best for you next week using this link:
Bitbucket Pipelines: Product Discussion - Rajkumar Singh

Once you’ve picked a slot, I’ll confirm the meeting and share an agenda so we can make the most of the discussion. Looking forward to speaking with you!

Samuel Mezger

Some information to (even succeeded) tests can be written to stdout. This is captured in <system-out> Tags in the JUnit formatted *.xml files. It would be very valuable to have access to this information when checking a test result.

As far as I can currently see, this is only available when we download the *.xml-Artifact and open that one, which is cumbersome.

Rajkumar Singh

@Samuel Mezger Thanks for the feedback — really appreciate it!

Some information to (even succeeded) tests can be written to stdout

Quick question: we do show the full stacktrace for the failed tests in the pipelines tab and for the passed tests is there any other specific information from the xml file you'd find useful to have surfaced directly in the UI?

Also, have you had a chance to explore the Tests feature in Bitbucket Pipelines? It shows detailed results for every test execution — including passed tests — with direct linkage to the corresponding build. That might already address part of what you're looking for.

Screenshot 2026-04-03 at 4.36.54 PM.png

Lastly, we'd love to learn more about your workflow. Would you be open to a quick call with our team? It would really help us prioritize improvements like this.

Looking forward to hearing from you!

Samuel Mezger

Hi @Rajkumar Singh ,

Yes, I use the Tests feature in Bitbucket Pipelines that you linked. This feature is what my comment is about, and this is why I posted it under this article about this feature.

As mentioned, this is about stdout output, not about the stack trace of failed tests. It is captured in the <system-out> Elements of the JUnit test report XML files. This information is valuable for us, regardless of whether tests failed or ran successfully.

Our workflow includes running Bitbucket Pipelines for building, testing and deploying, and the automated tests produce JUnit XML output. Tests may in some cases log some additional information to stdout. If logging to console, this is visible in the Pipeline step. If logging into JUnit XML, we can only see this output if we download the *.xml artifact and then open it. Potential for improvement in terms of user experience, and in terms of persistence of test results within Bitbucket Pipelines.

Nandakishore Malothvalapil Mohanan

👋 Hey everyone — circling back on the self-hosted runner question that @Jeff Cook , @Stijn Post and others raised earlier.
Update: Test reporting now works with self-hosted runners! 🎉
We've just rolled this out — here's what you need to know:

• Minimum runner version required: 3.25.0
• No pipeline YAML changes required.
• This is available on Standard and Premium plans.

Thanks for your patience! Drop a comment here if you hit any issues.

Stijn Post_abp8je

@Nandakishore Malothvalapil Mohanan Ok great, good to hear, is this still only available on the master branche? Or can we already set to have this run on 1 chosen branche OR on any?

Shubham Maheshwari

@Stijn Post We are pleased to announce an enhancement to Bitbucket Tests, which now supports tracking tests from up to 5 named git branches.

To learn more about the Bitbucket Tests feature, please review the blog post and documentation provided below.

Bitbucket Test now supports tracking tests from multiple branches: https://www.atlassian.com/blog/bitbucket/bitbucket-tests-tracks-tests-from-multiple-branches
Community Post: Bitbucket Tests(beta) now supports tracking tests from multiple branches: https://community.atlassian.com/forums/Bitbucket-articles/Bitbucket-Tests-beta-now-supports-tracking-tests-from-multiple/ba-p/3266036
Documentation: Configure multiple branches for tracking: https://support.atlassian.com/bitbucket-cloud/docs/test-reporting-in-pipelines/#Branch-tracking
Get started with tests in Pipelines: https://support.atlassian.com/bitbucket-cloud/docs/test-reporting-in-pipelines

blake.fletcher

This issue still appears to be present for self-hosted runners: https://community.atlassian.com/forums/discussion/3287625/quarantined-tests-are-not-written-into-bitbucket-test-metadata-file-path?utm_source=community-share