[website] _content/blog: fix synctest function name (Run -> Test)
Gerrit Bot (Gerrit)
Gerrit Bot has uploaded the change for review![]( "Open in Gerrit")
Commit message
_content/blog: fix synctest function name (Run -> Test)
While reading the Go blog I noticed the Test function was being incorrectly referenced as Run (likely due to Run being part of an earlier proposal)
Change diff
diff --git a/_content/blog/synctest.md b/_content/blog/synctest.md
index 72f5e3a..96b39b6 100644
--- a/_content/blog/synctest.md
+++ b/_content/blog/synctest.md
@@ -104,9 +104,9 @@
It allows us to rewrite this test to be simple, fast, and reliable,
without any changes to the code being tested.
-The package contains only two functions: `Run` and `Wait`.
+The package contains only two functions: `Test` and `Wait`.
-`Run` calls a function in a new goroutine.
+`Test` calls a function in a new goroutine.
This goroutine and any goroutines started by it
exist in an isolated environment which we call a *bubble*.
`Wait` waits for every goroutine in the current goroutine's bubble
@@ -116,7 +116,7 @@
{{raw `
func TestAfterFunc(t *testing.T) {
- synctest.Run(func() {
+ synctest.Test(t, func(t *testing.T) {
ctx, cancel := context.WithCancel(context.Background())
funcCalled := false
@@ -140,7 +140,7 @@
`}}
This is almost identical to our original test,
-but we have wrapped the test in a `synctest.Run` call
+but we have wrapped the test in a `synctest.Test` call
and we call `synctest.Wait` before asserting that the function has been called or not.
The `Wait` function waits for every goroutine in the caller's bubble to block.
@@ -173,7 +173,7 @@
The `testing/synctest` package makes it simpler to test code that uses time.
-Goroutines in the bubble started by `Run` use a fake clock.
+Goroutines in the bubble started by `Test` use a fake clock.
Within the bubble, functions in the `time` package operate on the
fake clock. Time advances in the bubble when all goroutines are
blocked.
@@ -185,7 +185,7 @@
{{raw `
func TestWithTimeout(t *testing.T) {
- synctest.Run(func() {
+ synctest.Test(t, func(t *testing.T) {
const timeout = 5 * time.Second
ctx, cancel := context.WithTimeout(context.Background(), timeout)
defer cancel()
@@ -208,7 +208,7 @@
`}}
We write this test just as if we were working with real time.
-The only difference is that we wrap the test function in `synctest.Run`,
+The only difference is that we wrap the test function in `synctest.Test`,
and call `synctest.Wait` after each `time.Sleep` call to wait for the context
package's timers to finish running.
@@ -222,7 +222,7 @@
- If there is an outstanding `Wait` call, it returns.
- Otherwise, time advances to the next time that could unblock a goroutine, if any.
- - Otherwise, the bubble is deadlocked and `Run` panics.
+ - Otherwise, the bubble is deadlocked and `Test` panics.
A bubble is not durably blocked if any goroutine is blocked
but might be woken by some event from outside the bubble.
@@ -281,12 +281,12 @@
## Bubble lifetime
-The `Run` function starts a goroutine in a new bubble.
+The `Test` function starts a goroutine in a new bubble.
It returns when every goroutine in the bubble has exited.
It panics if the bubble is durably blocked
and cannot be unblocked by advancing time.
-The requirement that every goroutine in the bubble exit before Run returns
+The requirement that every goroutine in the bubble exit before Test returns
means that tests must be careful to clean up any background goroutines
before completing.
@@ -319,7 +319,7 @@
{{raw `
func Test(t *testing.T) {
- synctest.Run(func() {
+ synctest.Test(t, func(t *testing.T) {
srvConn, cliConn := net.Pipe()
defer srvConn.Close()
defer cliConn.Close()
@@ -394,7 +394,7 @@
And finally, we finish up by sending the "200 OK" response to conclude the request.
We have started several goroutines during this test.
-The `synctest.Run` call will wait for all of them to exit before returning.
+The `synctest.Test` call will wait for all of them to exit before returning.
{{raw `
srvConn.Write([]byte("HTTP/1.1 200 OK\r\n\r\n"))
Change information
- M _content/blog/synctest.md
Related details
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Gopher Robot (Gerrit)
Gopher Robot added 1 comment![]( "Open in Gerrit")
I spotted some possible problems with your PR:
1. You have a long 147 character line in the commit message body. Please add line breaks to long lines that should be wrapped. Lines in the commit message body should be wrapped at ~76 characters unless needed for things like URLs or tables. (Note: GitHub might render long lines as soft-wrapped, so double-check in the Gerrit commit message shown above.)
2. You usually need to reference a bug number for all but trivial or cosmetic fixes. For the website repo, the format is usually 'Fixes golang/go#12345' or 'Updates golang/go#12345' at the end of the commit message. Should you have a bug reference?
Please address any problems by updating the GitHub PR.
When complete, mark this comment as 'Done' and click the [blue 'Reply' button](https://go.dev/wiki/GerritBot#i-left-a-reply-to-a-comment-in-gerrit-but-no-one-but-me-can-see-it) above. These findings are based on heuristics; if a finding does not apply, briefly reply here saying so.
To update the commit title or commit message body shown here in Gerrit, you must edit the GitHub PR title and PR description (the first comment) in the GitHub web interface using the 'Edit' button or 'Edit' menu entry there. Note: pushing a new commit to the PR will not automatically update the commit message used by Gerrit.
For more details, see:
- [how to update commit messages](https://go.dev/wiki/GerritBot/#how-does-gerritbot-determine-the-final-commit-message) for PRs imported into Gerrit.
- the Go project's [conventions for commit messages](https://go.dev/doc/contribute#commit_messages) that you should follow.
(In general for Gerrit code reviews, the change author is expected to [log in to Gerrit](https://go-review.googlesource.com/login/) with a Gmail or other Google account and then close out each piece of feedback by marking it as 'Done' if implemented as suggested or otherwise reply to each review comment. See the [Review](https://go.dev/doc/contribute#review) section of the Contributing Guide for details.)
Related details
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Gopher Robot (Gerrit)
Message from Gopher Robot![]( "Open in Gerrit")
Congratulations on opening your first change. Thank you for your contribution!
Next steps:
A maintainer will review your change and provide feedback. See
https://go.dev/doc/contribute#review for more info and tips to get your
patch through code review.
Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.
Related details
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Damien Neil (Gerrit)
Damien Neil added 1 comment![]( "Open in Gerrit")
The package contains only two functions: `Test` and `Wait`.On one hand, this change means that anyone who finds this blog post will see the current API.
On the other hand, this makes various other parts of the post inaccurate: The post leads with "In Go 1.24, we are introducing..." but the post no longer describes the API added in Go 1.24. It concludes with a mention that we may revise the API before adopting it, but does not explain that the post now describes the revised API.
I'm not certain what the right thing to do here is, but I don't think this is it.
Related details
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Bartek Ciszkowski (Gerrit)
Bartek Ciszkowski added 1 comment![]( "Open in Gerrit")
The package contains only two functions: `Test` and `Wait`.On one hand, this change means that anyone who finds this blog post will see the current API.
On the other hand, this makes various other parts of the post inaccurate: The post leads with "In Go 1.24, we are introducing..." but the post no longer describes the API added in Go 1.24. It concludes with a mention that we may revise the API before adopting it, but does not explain that the post now describes the revised API.
I'm not certain what the right thing to do here is, but I don't think this is it.
Good callout. I'm not certain what has been done for prior Go blog posts. Typically, this is not needed as Go has been so great at backwards compatibility and minimal API changes.
I see two pathways, dependent on what is preferable for the maintainers of this blog:
1. The post is prefixed with a note about API changes in the relevant versions of Go, calling out synctest.Run -> Test and that the blog post reflects a snapshot of Go at time of writing. The remainder of the blog post remains as-is.
2. The post is updated with correct API references, removes any notions of this being a draft API, and includes a prefixed note stating the post has been modified since the original publication.
The blog post shows up as one of the top results in various search engines (query "synctest golang"), so I feel accuracy to the current spec is preferred.
May be other pathways of course, just sharing my thoughts :-)
Related details
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Sean Liao (Gerrit)
Sean Liao added 1 comment![]( "Open in Gerrit")
The package contains only two functions: `Test` and `Wait`.Bartek CiszkowskiOn one hand, this change means that anyone who finds this blog post will see the current API.
On the other hand, this makes various other parts of the post inaccurate: The post leads with "In Go 1.24, we are introducing..." but the post no longer describes the API added in Go 1.24. It concludes with a mention that we may revise the API before adopting it, but does not explain that the post now describes the revised API.
I'm not certain what the right thing to do here is, but I don't think this is it.
Good callout. I'm not certain what has been done for prior Go blog posts. Typically, this is not needed as Go has been so great at backwards compatibility and minimal API changes.
I see two pathways, dependent on what is preferable for the maintainers of this blog:
1. The post is prefixed with a note about API changes in the relevant versions of Go, calling out synctest.Run -> Test and that the blog post reflects a snapshot of Go at time of writing. The remainder of the blog post remains as-is.
2. The post is updated with correct API references, removes any notions of this being a draft API, and includes a prefixed note stating the post has been modified since the original publication.
The blog post shows up as one of the top results in various search engines (query "synctest golang"), so I feel accuracy to the current spec is preferred.
May be other pathways of course, just sharing my thoughts :-)
This is a blog post with a timestamp, we generally don't heavily revise them.
I think just an additional sentence saying we changed it from Run to Test for Go 1.25 is sufficient.
If you want to read documentation, it should be in the package docs.
Related details
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |