I don’t feel at liberty to share the main project I’m prototyping, still. But I can give you all a little sneak peek at how testing is done for the typed identifiers crate!

I’m pretty proud of how it works:

• I have some files that dictate certain valid and invalid identifiers.
• At runtime, the data is expanded in a stress integration test.
• Each “test identifier” is visited, and based on the data, we attempt different operations, and validate against the test data.

Here’s an example for what this test data looks like (not actually in YAML format, just shown that way for example):

- name: "CaféPatron"
  kebab: true
  snake: true
  camel: true
  upper_camel: true
  segments:
  - !Chunk "Café"
  - !Boundary Camel
  - !Boundary Hat
  - !Chunk "Patron"

This entry says:

1. There’s a valid identifier that can parse as mixed-case kebab, mixed-case snake, mixed-case camel, or upper-camel.
2. Based on how the identifier is configured to respect chunk boundaries, it may or may not break apart Café from Patron (if CAMEL or HAT boundary options are enabled, specifically).
3. Tests segmentation using all combinations of options, and ensures that they return ["CaféPatron"] or ["Café", "Patron"] as expected.
4. Tests that case conversion works and respects chunk boundaries (e.g., when converting to another case, we have the same number of chunks, though they may now be slightly reformatted).

It also validates some inverse properties. For example, we cannot parse this as LowerSnakeIdent (according to the data), so we will validate that.