Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit the amount of value reflection data expectation checking collects by default #915

Merged
merged 3 commits into from
Jan 17, 2025

Conversation

stmontgomery
Copy link
Contributor

@stmontgomery stmontgomery commented Jan 16, 2025

This modifies the internal logic which recursively collects reflection data about values passed to #expect(...) and similar expectation APIs so that it imposes an artificial limit on the amount of data collected.

Motivation:

Some users have attempted to use #expect with instances of values with large collections or with deep value hierarchies involving many sub-properties, etc. In these situations they have noticed that the automatic value reflection is adding a noticeable amount of overhead to the overall test execution time, and would like to reduce that by default (near term), as well as have some ability to control that so the behavior could be tweaked for particular tests (in the future).

Modifications:

  • Add some new Configuration properties controlling data collection behaviors and setting default limits.
  • Consult these new configuration properties in the relevant places in Expression.Value.
  • Make Expression.Value.init(reflecting:) optional and return nil when value reflection is disabled in the configuration.
  • Add a new initializer Expression.Value.init(describing:) as a lighter-weight alternative to init(reflecting:) which only forms a string description of its subject, and adopt this as a fallback in places affected by the new optional in the previous bullet.
  • Add representative new unit tests.

Checklist:

  • Code and documentation should follow the style of the Style Guide.
  • If public symbols are renamed or modified, DocC references should be updated.

Fixes rdar://138208832

@stmontgomery stmontgomery added enhancement New feature or request tools integration Integration of swift-testing into tools/IDEs performance Performance issues labels Jan 16, 2025
@stmontgomery stmontgomery added this to the Swift 6.x milestone Jan 16, 2025
@stmontgomery stmontgomery self-assigned this Jan 16, 2025
/// maximum count. After this maximum is reached, all subsequent elements are
/// omitted and a single placeholder child is added indicating the number of
/// elements which have been truncated.
public var maximumValueReflectionCollectionCount: Int = 10
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
public var maximumValueReflectionCollectionCount: Int = 10
public var maximumValueReflectionCollectionCount = 10

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like having the types of properties with public or greater access level state their type explicitly, to avoid the possibility of the inferred type changing without our knowledge and causing a API breakage. I see now that we have not done this with some trivial properties in Configuration, but now that I've moved most of these into a nested struct I've used this style within that new struct at least. I'd like to apply this coding style more broadly in a subsequent PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We pretty much never do this for variables to which we assign values. We only specify types on variables that will be assigned values later. Consistency would be good (either way.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already merged, but I did strip off the explicit types from these properties for now, for consistency!

@grynspan
Copy link
Contributor

Also please keep #840 in the back of your mind as you make changes here.

@stmontgomery
Copy link
Contributor Author

@swift-ci please test

@stmontgomery stmontgomery requested a review from grynspan January 16, 2025 23:28
@stmontgomery
Copy link
Contributor Author

@swift-ci please test

@stmontgomery stmontgomery merged commit 6d20200 into swiftlang:main Jan 17, 2025
3 checks passed
@stmontgomery stmontgomery deleted the large-mirrors branch January 17, 2025 18:31
stmontgomery added a commit that referenced this pull request Jan 30, 2025
…#926)

This amends the code style guidelines for the project to require an
explicit type for all properties whose access level is `public` or
greater, and adjusts the code accordingly.

### Motivation:

See the explanation in the code style document for rationale. This topic
recently [came
up](#915 (comment))
in a PR discussion.

### Checklist:

- [x] Code and documentation should follow the style of the [Style
Guide](https://github.com/apple/swift-testing/blob/main/Documentation/StyleGuide.md).
- [x] If public symbols are renamed or modified, DocC references should
be updated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request performance Performance issues tools integration Integration of swift-testing into tools/IDEs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants