doctest

Overview

doctest is a header-only C++ testing framework. In practical terms, it gives maintainers and developers a lightweight way to write and run unit tests without turning the project into a large test harness. The upstream project presents doctest as a single-header framework for C++11 and newer, focused on low compile-time overhead and straightforward test organization. (github.com)

For a Linux distribution package, doctest usually exists so other packages can build and run their own C++ test suites against a small, packaged testing dependency instead of bundling a copy from source. NiceOS maintainers should still verify the exact packaging role in this repository and in reverse dependencies, because the same library may be used either as a build-time test dependency or as a development aid. (github.com)

Purpose and typical use cases

Typical uses include:

• unit testing C++ libraries and applications;
• embedding tests near the code they exercise;
• running project test binaries during CI/CD builds;
• supporting maintainers who need a compact framework for regression checks;
• helping developers add tests without introducing a large amount of test-only boilerplate. (github.com)

Typical users are:

• C++ developers who write or maintain tests;
• distribution packagers who need a clean system package for downstream builds;
• CI/CD maintainers who run automated test jobs;
• release or QA engineers who validate changes before publication;
• security engineers or reviewers who need to run test builds as part of verification, while keeping in mind that doctest itself is a general testing framework rather than a security tool.

Upstream project

The upstream project is hosted at the doctest GitHub repository. Its README describes doctest as a fast, feature-rich single-header testing framework for modern C++, with documentation, examples, and contributor guidance in the repository. (github.com)

If a maintainer needs deeper implementation details, the upstream documentation in the repository should be consulted first. Any packaging-specific assumptions about supported compilers, build modes, or test behavior should be verified against the upstream sources before being relied on in NiceOS. (github.com)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source metadata and manifests used to track upstream source integrity;
• METADATA/ — package metadata used by the dist-git workflow;
• SBOM/ — software bill of materials material, if maintained for this package.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps the metadata needed to identify and verify the expected sources. The exact manifest format may vary by package, so maintainers should inspect the files under SOURCES/ and confirm that the tracked source set matches the spec file.

Source storage and integrity policy

Source integrity is tracked through manifest files in SOURCES/, not by committing the full upstream archive into dist-git. This keeps the repository smaller and avoids storing large generated artifacts in version control.

Before updating the package, NiceOS maintainers should verify:

• that the upstream source referenced by the manifests is the intended one;
• that the spec file still matches the source layout;
• that no unexpected extra files were introduced upstream;
• that any packaging patches still apply cleanly;
• that any generated metadata remains in sync with the new upstream state.

If the package uses helper files or generated manifests, maintainers should check whether they need regeneration as part of the update. If that process is uncertain, it should be documented in the spec or in packaging notes before the next update is attempted.

NiceOS maintenance notes

When updating doctest in NiceOS, check at least the following:

• confirm whether the upstream project changed its file layout, documentation paths, or build expectations;
• review the spec file for build-system changes, installed headers, and test-related packaging rules;
• inspect SOURCES/ to confirm the manifest still points to the correct upstream source set;
• update any packaging notes that describe how the source is fetched or verified;
• review SBOM/ and any metadata files if your packaging workflow regenerates them;
• confirm that downstream consumers still compile against the packaged headers without requiring local patches.

Risks to consider:

• upstream changes in header layout can break downstream includes;
• a packaging patch may stop applying cleanly after a source change;
• test-related packages may expose new compiler diagnostics or stricter warnings;
• build behavior may differ across compilers or standard library versions, so maintainers should verify the package on the target NiceOS toolchain rather than assuming upstream results transfer directly.

Build and verification checklist

For RPM maintenance, a practical checklist is:

• review the spec diff before refreshing sources;
• verify the upstream source and manifests in SOURCES/;
• rebuild the SRPM and check that the source list matches expectations;
• run the package build in the target NiceOS buildroot;
• confirm that installed headers land in the expected path;
• run downstream test builds that use doctest, if available;
• check for packaging warnings, missing files, and accidental test or documentation omissions;
• verify that any SBOM or metadata files remain consistent with the package contents;
• inspect the resulting RPM for only the intended files.

If the package ships only headers, the most useful validation is usually compile-time compatibility with a downstream consumer rather than a runtime smoke test.

References

• doctest upstream repository
• doctest documentation and FAQ in the upstream repository

Russian documentation

See README_RU.md for the Russian version of this document.

Dist-git repository notes

• Package repository: rpms/doctest
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.