1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
//! Test definitions.
//!
//! This module defines what a test is in Kitest.
//!
//! The central type is [`Test`]. It represents a single executable test together with
//! its associated metadata. All test harnesses in Kitest operate on collections of
//! [`Test`] values.
use ;
use crate::;
/// A single test case.
///
/// [`Test`] is the main test apparatus in Kitest. This is the type a harness operates on.
/// A harness takes a slice of tests and uses their metadata and execution handle to run,
/// list, filter, ignore, group, and report them.
///
/// A `Test` consists of:
///
/// - a [`TestFnHandle`] that knows how to execute the test
/// - a [`TestMeta<Extra>`] value that describes the test
///
/// ## Use case specific metadata with `Extra`
///
/// The `Extra` type parameter is user defined metadata attached to the test.
/// Nearly everything in Kitest is generic over `Extra`, so strategies can use this data without
/// runtime casts.
///
/// All default strategies work with any `Extra` type.
/// Custom strategies may choose to require a specific `Extra` type, for example a flag enum or a
/// struct with tags.
///
/// If no custom metadata is needed, `Extra` can be `()`.
/// Kitest treats this as the "no extra data" case, which keeps types easy to write.
///
/// ## Const friendly
///
/// A `Test` can be created at compile time.
/// This makes it possible to define tests as `const` values and collect them at build time,
/// instead of running collection code when the test binary starts.
/// Metadata describing a test.
///
/// [`TestMeta`] contains information about a test without any execution context.
/// Some strategies intentionally only see metadata, so they can make decisions
/// (filtering, ignoring, grouping, formatting) without any risk of accidentally executing a test
/// at the wrong place.
///
/// All fields are designed to be constructible in `const` contexts.
/// This allows building tests at compile time.
/// Types like [`Cow<'static, str>`] are used for this reason.
///
/// The generic `Extra` parameter stores user provided metadata used to annotate tests for a
/// specific use case.
/// Describes where a test comes from.
///
/// A [`TestOrigin`] is optional metadata that can be attached to [`TestMeta`].
/// It is meant to help users find the source of a test, for example a file on disk, a generated
/// fixture, or some external system.
///
/// Kitest's built-in formatters treat the origin as display text and simply call
/// [`Display`] on it when they want to refer to a test source.
///
/// The [`origin!`](crate::origin) macro produces `Some(TestOrigin::TextFile { .. })` at the call
/// site, so it can be used to stamp tests with a source location easily.
/// Capture the source location where a test is defined.
///
/// This macro produces `Some(TestOrigin::TextFile { .. })` using the call site
/// information of the macro invocation.
///
/// It records:
/// - the file path
/// - the line number
/// - the column number
///
/// The resulting [`TestOrigin`] is formatted as `{file}:{line}:{column}`, which is
/// understood by most editors and terminals and allows jumping directly to the
/// source location.
///
/// This macro is most useful when building your own test definition macros.
/// In that setup, each test can automatically carry the location of the macro call,
/// even if the test is later executed from a generated list or a distributed slice.
/// Describes how a test is executed.
///
/// [`TestFnHandle`] is the executable part of a [`Test`]. It stores a callable value that
/// produces a [`TestResult`].
///
/// Kitest supports multiple ways of storing a test function, so tests can be created in
/// `const` contexts, generated by macros, or built dynamically at runtime.
/// A callable test function.
///
/// [`TestFn`] is a small trait used by [`TestFnHandle`] to execute tests behind a trait object.
/// It represents "something that can be called and produces a [`TestResult`]".
///
/// In theory, this could be modeled directly with Rust's built-in [`Fn`] traits.
/// At the time of writing, implementing `Fn` for arbitrary user types is not available on stable
/// Rust, so Kitest uses this dedicated trait instead.
///
/// Kitest provides a blanket implementation for any function or closure that returns something
/// convertible into a [`TestResult`].
/// This includes:
///
/// - `()`
/// - `Result<T, E>` where `E: Debug`
///
/// This makes normal test functions work naturally, while still allowing custom closures or
/// adapters to be stored as `dyn TestFn`.
/// The result type returned by a test function.
///
/// [`TestResult`] is what a [`TestFnHandle`] produces when a test is executed.
/// A test either succeeds or fails, and may optionally carry extra data for other parts of the
/// framework.
///
/// Internally this is a `Result<Option<Whatever>, Whatever>`:
///
/// - `Ok(None)` means the test passed and did not produce extra data.
/// - `Ok(Some(_))` means the test passed and returned additional information.
/// - `Err(_)` means the test failed and carries structured failure data.
///
/// The common path is `Ok(None)`, which does not allocate and is very cheap.
/// Only when a test attaches extra data or fails do we allocate a [`Whatever`].
///
/// Using [`Whatever`] allows tests and runners to attach type erased but still
/// strongly bounded values. Consumers that know the concrete type can
/// downcast and recover the original value, enabling richer reporting and
/// integration without pushing more generics through the core API.
///
/// `TestResult` is designed to be ergonomic:
///
/// - It can be created from `()`, which maps to `Ok(None)`.
/// - It can be created from `Result<(), E>` where `E: Error`. On failure,
/// the error is converted into a `Whatever`, preserving its formatted
/// representation while fitting into the unified result type.
///
/// While typically returned from regular Rust test functions, a runner may
/// also construct a `TestResult` directly, for example when validating
/// fixtures or aggregating diagnostics.
;