A test has a dependency on database.query. During the test the dependency is replaced with an object called database with the method, query, that…

The scenario describes replacing a real dependency (database.query) with a test double. This technique is known as Mocking. Mocks are configured with expectations about how they will be used (e.g., number of calls, arguments) and can verify these interactions.

This approach is also a form of White-box testing. White-box testing requires knowledge of the internal implementation of the code. Verifying that a specific internal method was called a certain number of times with specific arguments is a classic example of testing the code's internal logic and structure, rather than just its external output.

A. Integration: Integration testing verifies that different modules work together. The described approach does the opposite by isolating the unit from its database dependency.

B. Black box: Black-box testing evaluates functionality without knowledge of the internal implementation. This test specifically inspects internal behavior (method calls and arguments).

1. Salesforce Lightning Web Components Developer Guide: The section on Jest testing explicitly details the use of mocks to isolate components from dependencies. It states, "To test a component in isolation, mock its dependencies... Jest provides a mocking framework that you can use." This directly supports the concept of Mocking (D).

Source: Lightning Web Components Developer Guide, Module: Test Lightning Web Components, Section: Mock Dependencies.

2. Salesforce Lightning Web Components Developer Guide: The guide shows examples of verifying interactions with mocks using matchers like toHaveBeenCalled() and toHaveBeenCalledWith(). This verification of internal logic is a hallmark of White-box testing (C).

Source: Lightning Web Components Developer Guide, Module: Test Lightning Web Components, Section: Verify a Mock Was Called.

3. MIT OpenCourseWare, 6.031: Software Construction: Course materials define testing strategies. White-box testing is described as choosing test cases based on the code's internal structure, including statements and paths exercised. Verifying internal method calls fits this definition.

Source: MIT OpenCourseWare, 6.031 Software Construction, Spring 2016, Reading 16: Testing. Section: "Whitebox testing".

4. Martin Fowler, "Mocks Aren't Stubs": This foundational article, widely cited in academic and professional software engineering contexts, defines a mock as an object that verifies behavior. The question's requirement to "verify how many times the method was called and the arguments used" is the primary purpose of a mock object.

Source: Fowler, M. (2007). Mocks Aren't Stubs. martinfowler.com. Section: "Mocks".