Sync counts

office.stats() resolves to { syncs, actions } since the last office.mark() or reset, so a test can hold an operation to a sync budget. Each context.sync() is a round trip to Word, so extra syncs make an add-in slow:

it('redlines a clause in three syncs or fewer', async () => {
  await office.mark();
  await redlineClause('30 days', '45 days');
  expect((await office.stats()).syncs).toBeLessThanOrEqual(3);
});

Name the actions a test sent

office.batches() resolves to each batch since the mark, numbered from it, with every action named by its type and the object it acts on: { sync: 1, actions: ['Instantiate', 'SetProperty ChangeTrackingMode', 'Query Body._Search2()'] }. The simulator keeps its latest 128 batches since the last reset at GET /_rystic/inspect?view=officejs-batches, and a corpus run’s batch log has each test’s.

Read the counts from a browser test

The counts live on the simulator, so a browser test reads them without the harness. GET /_rystic/inspect?view=officejs returns the counts since the last reset, such as {"syncs": 2, "actions": 15, "epoch": 3}, and epoch changes on every reset.

What each count includes

• syncs is one for each context.sync(), including each one inside a Word.run that syncs several times.
• actions is what office.js packed into those batches: each load, method call, property write and kept reference.
• office.js’s own batches are not counted: the one that releases a Word.run’s tracked objects after it returns, and the one that reports the add-in ready after Office.onReady. When each lands is a race.