What type of testing would typically mock the results from each SELECT statement rather than actually execute it in the production database?

An API implementation is being developed to expose data from a production database via HTTP requests. The API implementation executes a database SELECT statement that is dynamically created based upon data received from each incoming HTTP request. The developers are planning to use various types of testing to make sure the Mule application works as expected, can handle specific workloads, and behaves correctly from an API consumer perspective.

What type of testing would typically mock the results from each SELECT statement rather than actually execute it in the production database?
A . Unit testing (white box)
B . Integration testing
C . Functional testing (black box)
D . Performance testing

Answer: A

Explanation:

In Unit testing instead of using actual backends, stubs are used for the backend services. This ensures that developers are not blocked and have no dependency on other systems.

In Unit testing instead of using actual backends, stubs are used for the backend services. This ensures that developers are not blocked and have no dependency on other systems. Below are the typical characteristics of unit testing.

— Unit tests do not require deployment into any special environment, such as a staging environment

— Unit tests san be run from within an embedded Mule runtime

— Unit tests can/should be implemented using MUnit

— For read-only interactions to any dependencies (such as other APIs): allowed to invoke production endpoints

— For write interactions: developers must implement mocks using MUnit

— Require knowledge of the implementation details of the API implementation under test