How can I test async code that succeeds, rejects, or returns empty data?

Start with three cases for the function’s main dependency: it resolves with ordinary data, rejects with an error, or resolves with an empty result. Use a local stub—a substitute that returns data you control—rather than real credentials or a live service. Stubs can simulate success, failures, and edge cases; mocks can also record calls. [S1]

Treat these as distinct outcomes. Empty data is not automatically a failure: it may be a valid result that your function should pass through or turn into a friendly message. Write down the intended behavior before choosing assertions. The source guidance discusses Node.js’s built-in test runner, Jest, and Vitest, but it does not establish one framework’s exact current syntax or setup. Follow the documentation for the framework your project uses. [S1]

Here is a framework-neutral matrix. Assume loadItems calls an injected fetchItems function and returns its result. Replace the expected behavior with your own contract if, for example, your function converts errors into a status object.

1. Success: dependency resolves to [{ id: 'a' }]; assert loadItems() resolves to that item.
2. Rejection: dependency rejects with Error('offline'); assert loadItems() rejects with the expected error, or with the documented transformed result.
3. Empty result: dependency resolves to []; assert loadItems() resolves to [] if empty collections are passed through.

Example test logic, expressed as pseudocode rather than framework-specific assertion syntax:

stub fetchItems to resolve with [{ id: 'a' }]
assert awaiting loadItems() equals [{ id: 'a' }]

stub fetchItems to reject with Error('offline')
assert awaiting loadItems() rejects with the expected error

stub fetchItems to resolve with []
assert awaiting loadItems() equals []

Make each test set its own stub behavior. That keeps one case’s setup from silently determining another case’s result. The assertions above describe intent; they are not copy-paste syntax for a particular runner.

Suppose the function simply delegates and returns the result. These are illustrative assumptions, not a claim about any particular project:

async function loadItems(fetchItems) {
  return await fetchItems()
}

For the success case, make the stub return [{ id: 'a' }], then check that awaiting loadItems(stub) gives the same value. For rejection, make the stub reject with Error('offline'), then check that awaiting the call rejects as expected. For empty data, make it resolve to [], then check that the result is an empty array—not an error—if that is the intended contract.

If your real function catches errors, changes the result shape, or retries, test that behavior instead of assuming this simple example applies. The source supports controlled stubs and edge-case testing, but does not establish your function’s intended contract or provide framework-specific assertion code. [S1]

Use the function’s public behavior as the target: what value does a caller receive, and how is a failure represented? Keep the fixture small and artificial, such as an item with a placeholder ID, and avoid personal data. Add a fourth case only when it checks a distinct promised behavior—for example, a rejected dependency that your function is supposed to convert into a fallback. Don’t add cases merely to duplicate the same outcome.

Before adopting a framework’s APIs, confirm its current setup and assertion syntax in that framework’s documentation. The cited Microsoft guidance covers several testing approaches, but it is Azure SDK integration-testing guidance, not a complete framework-independent manual. [S1]