Oplog sampling has two access methods: (1) random cursor, or (2) collection scanning. Writing a large amount of oplog data isn't ideal, as it increases test runtime, so introducing "slowness" to sampling seems like the way to go. Both access methods should be tested. The main things to test while asynchronous oplog sampling is running are that

1. Startup finishes, and users can connect to the database
2. CRUD and DDL operations can be performed 
3. Internal threads are working as expected such as: oplog application, TTL, backups, and oplog visibility to name a few.
4. Observability to ensure there are no gaps, and oplog sampling progress is clear in the logs and FTDC.