You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/src/advanced.md
+38-1Lines changed: 38 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -95,6 +95,38 @@ end # hide
95
95
96
96
The `init_code` is evaluated in each test's sandbox module, so all definitions are available to your test files.
97
97
98
+
## Worker Initialization
99
+
100
+
For most situations, `init_code` described above should be used. However, if the common code takes so long to import that it makes a notable difference to run before every testset, you can use the `init_worker_code` keyword argument in [`runtests`](@ref) to have it run only once at worker initialization. However, you will also have to import the directly-used functionality in your testset module using `init_code` due to the way ParallelTestRunner.jl creates a temporary module for each testset.
101
+
102
+
The example below is trivial and `init_worker_code` would not be necessary if this were used in a package, but it shows how it should be used. A real use-case of this is for tests using the GPUArrays.jl test suite; including it takes about 3s, so that 3s running before every testset can add a significant amount of runtime to the various GPU backend testsuites as opposed to running once when the runner is initally created.
103
+
104
+
```@example mypackage
105
+
using ParallelTestRunner
106
+
using MyPackage
107
+
108
+
const init_worker_code = quote
109
+
# Common code that's slow to import
110
+
function complex_common_test_helper(x)
111
+
return x * 2
112
+
end
113
+
end
114
+
115
+
const init_code = quote
116
+
# ParallelTestRunner creates a temporary module to run
117
+
# each testset. `init_code` runs in this temporary module,
118
+
# but code from `init_worker_code` that will be directly
119
+
# called in a testset must be explicitly included in the
The `init_worker_code` is evaluated once per worker, so all definitions can be imported for use by the test module.
129
+
98
130
## Custom Workers
99
131
100
132
For tests that require specific environment variables or Julia flags, you can use the `test_worker` keyword argument to [`runtests`](@ref) to assign tests to custom workers:
@@ -134,6 +166,11 @@ The `test_worker` function receives the test name and should return either:
134
166
- A worker object (from [`addworker`](@ref)) for tests that need special configuration
135
167
-`nothing` to use the default worker pool
136
168
169
+
!!! note
170
+
If your test suite uses both a `test_worker` function and `init_worker_code` as described in a prior section,
171
+
`test_worker` must also take in `init_worker_code` as a second argument. You are responsible for passing it to
172
+
[`addworker`](@ref) if your `init_code` depends on any `init_worker_code` definitions.
173
+
137
174
## Custom Arguments
138
175
139
176
If your package needs to accept its own command-line arguments in addition to `ParallelTestRunner`'s options, use [`parse_args`](@ref) with custom flags:
@@ -200,7 +237,7 @@ function jltest {
200
237
201
238
1.**Keep tests isolated**: Each test file runs in its own module, so avoid relying on global state between tests.
202
239
203
-
1.**Use `init_code` for common setup**: Instead of duplicating setup code in each test file, use `init_code` to share common initialization.
240
+
1.**Use `init_code` for common setup**: Instead of duplicating setup code in each test file, use `init_code` to share common initialization. For long-running initialization, consider using `init_worker_code` so that it is run only once per worker creation instead of before each test.
204
241
205
242
1.**Filter tests appropriately**: Use [`filter_tests!`](@ref) to respect user-specified test filters while allowing additional programmatic filtering.
0 commit comments