An email-dependent test includes several clocks. Measuring only the interval between two browser actions hides where time was spent and can make a mailbox change look like an application improvement.
Record the stages separately
| Stage | Useful timestamp |
|---|---|
| Application trigger | When the test requests a verification message. |
| Sender submission | When the sending system accepts or queues it, if observable. |
| Receiver observation | When the matching message becomes available to the test. |
| Verification result | When the application confirms the intended account state. |
Use a common clock where possible, record timezone assumptions and distinguish missing timestamps from zero duration. Compare repeated runs under the same conditions before making performance claims.
Choose the supported update mechanism
Server-sent events allow a server to send updates over an established browser connection. They can reduce repeated frontend polling, but delivery still depends on the underlying processing and network. See MDN's overview. A website using SSE does not mean its public API exposes the same stream.
For API tests, follow the documented interface. If polling is required, use bounded backoff, a deadline and message correlation instead of a tight loop.
Measure failures as well as averages
Report timeouts, rejected access, sender errors and unmatched messages alongside successful timings. A lower average among successes can hide an increase in failures. Keep sanitized traces for diagnosis without logging verification tokens.
Control the test's own workload
Limit simultaneous jobs, cancel work after the deadline and clean up synthetic artifacts. The implementation language and database do not establish a fixed capacity or make scaling free; measure the resources consumed by the actual workload.