Skip to content

Fix JUnit output for assertion-free test cases - #3187

Open
Boulea7 wants to merge 1 commit into
catchorg:develfrom
Boulea7:fix/junit-empty-testcase
Open

Fix JUnit output for assertion-free test cases#3187
Boulea7 wants to merge 1 commit into
catchorg:develfrom
Boulea7:fix/junit-empty-testcase

Conversation

@Boulea7

@Boulea7 Boulea7 commented Aug 10, 2026

Copy link
Copy Markdown

Description

The JUnit reporter currently omits an executed test case when it completes without assertions. This makes its result disagree with the console reporter and can leave JUnit consumers with no <testcase> node even though the test ran.

This change emits a <testcase> when an executed test would otherwise produce none. The suite tests attribute is derived from the testcase nodes written by the reporter, so the declared count matches the XML output. The fallback is limited to an otherwise empty section tree, which prevents assertion-free section and generator output from receiving a duplicate root testcase.

Validation

  • Approval tests
  • Basic development suite: 82/82 tests passed
  • All-tests configuration: 141/141 tests passed
  • Direct XML checks for an empty test, an assertion-free section, an assertion-free generator, a runtime skip, and a no-match filter

GitHub Issues

Fixes #2856

AI assistance

OpenAI Codex assisted with implementation and test preparation.

Emit a testcase for executed test cases whose section tree would otherwise produce no JUnit testcase. Count the suite tests from emitted testcase nodes so the declared count matches the XML output.

Fixes catchorg#2856

Assisted-by: OpenAI Codex
@codecov

codecov Bot commented Aug 10, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 96.29630% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 91.24%. Comparing base (97ec4e8) to head (ac97fb3).

Additional details and impacted files
@@            Coverage Diff             @@
##            devel    #3187      +/-   ##
==========================================
- Coverage   91.25%   91.24%   -0.01%     
==========================================
  Files         204      204              
  Lines        8965     8986      +21     
==========================================
+ Hits         8181     8199      +18     
- Misses        784      787       +3     
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@tteo38472

Copy link
Copy Markdown

Enterprise accounts

Get started with top-down administration by understanding the key components of an enterprise account.

An enterprise account is the central point of administration for your business on GitHub. It brings together administrative tools for access management, policies, billing, and more. Enterprise administrators can set up features and policies efficiently at scale before deploying them across the business.

This guide provides an overview of the major administrative features included in an enterprise account. By understanding the tools at your disposal, you will be able to adapt GitHub to your unique needs, set your business up for future scaling, and enable teams to focus on strategic work.

Users

Your enterprise contains all the users who need to access any part of your company's resources on GitHub. Users can be grouped into teams and given access to organizations.

Depending on your enterprise type, you will invite users into your enterprise with their existing GitHub account, or provision dedicated accounts from a central identity provider.

By default, most users have a non-administrative role in your enterprise, which means they have little reason to interact with the enterprise account itself. However, you can change this by granting enterprise roles that provide access to specific settings.

Organizations

An enterprise account may contain one or more organizations. Like an enterprise account, an organization account contains its own administrative features such as audit logs, policies, and teams.

An organization also contains the places where non-admins typically do their work, such as repositories, discussions, and projects. The users in an organization are the people who need to access these places to do their jobs.

Generally, you can govern organizations consistently from your enterprise account. To allow for more tailored and granular administration, you can also delegate some decisions, such as policy settings, to organization administrators.

Teams

Teams are groups of users that you can use to manage people's access to organizations, roles, and licenses at scale. You can use teams to add people to shared projects or delegate duties to specialized teams.

You can define teams at the enterprise level, then grant them administrative roles or add them to organizations, where they can receive organization-level roles and repository access.

Teams can be synced with IdP groups, allowing you to manage any privileges that come with team membership directly from your company's centralized identity management system.

Repositories

Repositories host files such as your company's source code or internal documentation. They are where developers typically do their work, and they contain their own features and administration options that need to live closer to the code, such as GitHub Actions workflows.

Repositories are owned by organizations and are not directly accessible under the enterprise account. However, your enterprise can define custom properties to apply the same governance model to all repositories with shared characteristics. For example, if you do not want anyone to delete repositories that contain production code, this is something you can govern from the enterprise level.

Cost centers

Cost centers allow you to allocate spending on GitHub features to specific business units. They let you define your billing structure independently from other parts of the enterprise, so you can focus on using organization accounts to group related work or governance requirements.

If your account is billed through Azure, cost centers also allow you to bill usage to multiple different Azure subscriptions.

Policies

Enterprise administrators can set policies to govern how people work across your enterprise, such as:

  • IP allow lists to enforce restrictions on where people can access your enterprise
  • Copilot policies to govern which features and models people can use
  • Repository policies to control who can do things like delete, rename, or transfer repositories
  • Rulesets to define how people can interact with important branches, such as requiring pull requests with reviews

Apps

GitHub Apps are a secure way to manage automations across your enterprise. A GitHub App is a dedicated identity that provides scoped tokens to your external scripts and workflows, allowing you to automate processes and integrate with other platforms.

In your enterprise account, you can define app registrations to automate a process consistently across organizations. You can also install apps for automations that take actions on the enterprise account itself, such as creating organizations.

Users can also authorize GitHub Apps to use their GitHub account and data in other applications—for example, to use their GitHub account to sign in to an IDE or connect a CI provider to your repositories.

Next steps

Learn how to set up these features with our Enterprise onboarding journey for GitHub Enterprise Cloud.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JUnit and console reporter discrepency.

2 participants