add dune describe tests subcommand

[Gromototo]

Objective

Add a new dune describe tests subcommand to display information about test and cram stanzas defined in the current project.

This information includes metadata such as:

• name: The test name
• source_dir: Directory containing the test stanza
• package: Associated package (if any)
• enabled: Whether the test is enabled (respects enabled_if conditions)
• location: Source location of the stanza definition
• target: Actionable build target (.exe for unit tests, @dir/runtest alias for CRAM tests)

Implementation

Core Architecture

• Dual stanza support: Handles both Tests.T (unit tests) and Cram_stanza.T (CRAM tests)
• Refactored logic: Separates collection (collect_test_stanzas) from transformation (describe_stanza) for clarity and maintainability
• Actionable targets:
  • Unit tests: _build/default/<dir>/<name>.exe
  • CRAM tests: @<source_dir>/runtest (alias target)
  • Inline tests: @<source_dir>/runtest-<lib_name> (alias target, e.g., for ppx_expect)
• Crawl pattern: Uses existing Dune crawl infrastructure and Dyn serialization for consistency with other describe subcommands
• Output formats: Supports both human-readable S-expression and canonical S-expression (--format=csexp)
• Complete reporting: Includes all tests regardless of enabled status (the boolean value indicates whether the test would run)

Technical Details

• Added logic to inspect the sub_systems field of Library.T for Inline_tests_info.Tests.name.
• Exposed Cram_stanza via dune_rules module for type matching
• Resolved namespace conflicts (Context_name.Map, Import.Main)
• Scoped Memo.O usage to avoid operator conflicts with Cmdliner.Term

Testing

Added comprehensive blackbox test coverage in test/blackbox-tests/test-cases/describe/describe-tests.t:

Phase 1: Unit Tests (Tests.T)

• Simple tests with basic metadata
• Complex tests with full metadata (package, dependencies)
• Multiple tests in a single stanza
• Disabled tests (via enabled_if)
• Tests with dependencies

Phase 2: CRAM Tests (Cram_stanza.T)

• Simple CRAM tests
• CRAM tests with package association
• Disabled CRAM tests

Phase 3: Inline Tests (Library.T / ppx_expect)

• Tests for libraries with (inline_tests).

Fixes

Closes #12030

[rgrinberg]

Looks like a good start. I think you should start with a human readable format before moving on to machine readable formats though.

Following that, the most important extension to this work would be to support cram and ppx_expect tests. Those are at least as important as tests defined using the "test" stanza.

[rgrinberg]

I think the fact that multiple tests can be define in one stanza isn't something that the describe command should necessarily display. A separate test entry for each test in the same stanza seems easier for tools/users to make use of.

[Gromototo]

I went with your suggestion. I updated the implementation so that each test in a multi-test stanza is listed individually in the dune describe tests output.

[Gromototo]

Looks like a good start. I think you should start with a human readable format before moving on to machine readable formats though.

Following that, the most important extension to this work would be to support cram and ppx_expect tests. Those are at least as important as tests defined using the "test" stanza.

Since implementing Cram stanzas is straightforward, I included Cram support in the new revision.

Supporting ppx_expect tests is less direct, as they are not defined in configuration files. Handling them would likely require parsing the test files themselves ?

[rgrinberg]

Supporting ppx_expect tests is less direct, as they are not defined in configuration files. Handling them would likely require parsing the test files themselves ?

Right, it's a bit more difficult. I don't think you need to parse the tests themselves (although that would certainly be a good thing too). It's enough to just rely on the rules to discover the test files. That would already be enough granularity.

What do you think about dropping the wrap sexp around the output like $ dune describe workspace? I don't think it buys us much.

PS: CI is pointing out some minor issues

[Gromototo]

What do you think about dropping the wrap sexp around the output like $ dune describe workspace? I don't think it buys us much.

I understood that you suggested removing the outer parenthesis for the output (like dune describe workspace) so that we delete the empty space in front of each test entry when displaying it.

I tried implementing this by iterating over the descriptions list and print them individually, rather than letting the pretty-printer handle the whole list at once.

However, doing this caused the pretty-printer to format each test independently, which resulted in strange, inconsistent indentations for tests with long fields.

Since it was only a suggestion and the inconsistent formatting is worse, I went for updating the PR without it for now

[Alizter]

One more field I would add here is the test alias. For the tests stanza this will just be runtest-nameoftest, same for inline tests and for cram tests it should be cramtest for cramtest.t.

[Alizter]

This is what dune runtest is doing for cram tests for instance, it takes a source file and then finds the alias associated with it and runs that. There is work in progress for inline tests and tests stanzas.

[rgrinberg]

One reason to prefer multiple test stanzas instead of a single massive stanza is because this matches better how the stanzas are defined. I think we should have probably went for this approach for dune describe workspace as well. It's not such an important detail though.