Skip to content

chore: add README to clock testing #13583

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

Merged
merged 1 commit into from
Jun 18, 2024
Merged

Conversation

spikecurtis
Copy link
Contributor

@spikecurtis spikecurtis commented Jun 17, 2024

Adds README with some draft content explaining why the library exists. Will be most relevant when we spin out into a standalone library.

Copy link
Contributor Author

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @spikecurtis and the rest of your teammates on Graphite Graphite

@spikecurtis spikecurtis marked this pull request as ready for review June 17, 2024 06:08
Copy link
Member

@johnstcn johnstcn left a comment

Choose a reason for hiding this comment

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

Some minor language nits, otherwise nice writeup!

clock/README.md Outdated
* [github.com/aspenmesh/tock](https://github.com/aspenmesh/tock)

Quartz shares the high level design of a `Clock` interface that closely resembles the functions in
the `time` standard library, and a "real" clock passes thru to the standard libary in production,
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
the `time` standard library, and a "real" clock passes thru to the standard libary in production,
the `time` standard library, and a "real" clock passes through to the standard library in production,

Copy link
Contributor Author

Choose a reason for hiding this comment

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

clock/README.md Outdated
Comment on lines 9 to 10
Writing good unit tests for components and functions that use the `time` package is difficult, and
several open source libraries exist. In building Quartz, we took some inspiration from
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
Writing good unit tests for components and functions that use the `time` package is difficult, and
several open source libraries exist. In building Quartz, we took some inspiration from
Writing good unit tests for components and functions that use the `time` package is difficult, even though
several open source libraries exist. In building Quartz, we took some inspiration from

clock/README.md Outdated
Comment on lines 103 to 106
(As an aside, we still support a traditional standard library-style `Ticker`, if you want to keep
your code as close as possible to the standard library, or if you need to use the channel in a
larger `select` block, but in that case you'll have to find some other mechanism to sync tick
processing to your test code.)
Copy link
Member

Choose a reason for hiding this comment

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

Run-on sentence, consider breaking up.

Our high level goal is to write unit tests that

1. execute quickly
2. don't flake
Copy link
Member

Choose a reason for hiding this comment

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

suggestion: avoid colloquialism

Suggested change
2. don't flake
2. execute reliably

Copy link
Contributor Author

@spikecurtis spikecurtis Jun 17, 2024

Choose a reason for hiding this comment

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

While arguably "jargon", I think flaky is more precise. It refers to tests that succeed or fail due to uncontrolled randomness.

A test might not be reliable for other reasons, such as not actually testing or asserting the thing it purports to.

For several reasons, this is a tall order when it comes to code that depends on time, and we found
the existing libraries insufficient for our goals.

For tests to execute quickly without flakes, we want to focus on _determinism_: the test should run
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
For tests to execute quickly without flakes, we want to focus on _determinism_: the test should run
For tests to execute quickly and reliably, we want to focus on _determinism_: the test should run

@spikecurtis spikecurtis force-pushed the spike/clock-testing-readme branch from e4294f1 to ba76a30 Compare June 17, 2024 08:11
@spikecurtis spikecurtis merged commit 1de023a into main Jun 18, 2024
24 checks passed
@spikecurtis spikecurtis deleted the spike/clock-testing-readme branch June 18, 2024 06:16
@github-actions github-actions bot locked and limited conversation to collaborators Jun 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants