@FunctionalInterface public interface MockDataProvider
Supply this data provider to your MockConnection
in order to globally
provide data for SQL statements.
The general idea of mocking a JDBC connection with this jOOQ API is to
provide quick workarounds, injection points, etc. using a very
simple JDBC abstraction (see the execute(MockExecuteContext)
method). It is NOT RECOMMENDED to emulate an entire database
(including complex state transitions, transactions, locking, etc.) using this
mock API. Once you have this requirement, please consider using an actual
database instead for integration testing, rather than implementing your test
database inside of a MockDataProvider
.
See execute(MockExecuteContext)
for more details.
MockConnection
Modifier and Type | Method and Description |
---|---|
MockResult[] |
execute(MockExecuteContext ctx)
Execution callback for a JDBC query execution.
|
MockResult[] execute(MockExecuteContext ctx) throws SQLException
This callback will be called by MockStatement
upon the various
statement execution methods. These include:
Statement.execute(String)
Statement.execute(String, int)
Statement.execute(String, int[])
Statement.execute(String, String[])
Statement.executeBatch()
Statement.executeQuery(String)
Statement.executeUpdate(String)
Statement.executeUpdate(String, int)
Statement.executeUpdate(String, int[])
Statement.executeUpdate(String, String[])
PreparedStatement.execute()
PreparedStatement.executeQuery()
PreparedStatement.executeUpdate()
The various execution modes are unified into this simple method. Implementations should adhere to this contract:
MockStatement
does not distinguish between "static" and
"prepared" statements. However, a non-empty
MockExecuteContext.bindings()
is a strong indicator for a
PreparedStatement
.MockStatement
does not distinguish between "batch" and
"single" statements. However...
MockExecuteContext.batchSQL()
with more than one SQL string
is a strong indicator for a "multi-batch statement", as understood by
jOOQ's DSLContext.batch(Query...)
.MockExecuteContext.batchBindings()
with more than one bind
variable array is a strong indicator for a "single-batch statement", as
understood by jOOQ's DSLContext.batch(Query)
.MockResult
objects
as batch executions. In other words, you should guarantee that:
int multiSize = context.getBatchSQL().length;
int singleSize = context.getBatchBindings().length;
assertEquals(result.length, Math.max(multiSize, singleSize))
This holds true also for non-batch executions (where both sizes are equal
to 1
)
Statement.getMoreResults()
.ResultQuery.fetchMany()
Statement.RETURN_GENERATED_KEYS
) are
requested from this execution, you can also add MockResult.data
to your result, in addition to the affected MockResult.rows
. The
relevant flag is passed from MockStatement
to any of these
properties:
MockResult
's first Record
. If OUT parameters are
requested, implementors must ensure the presence of such a
Record
.ctx
- The execution context.null
or an empty
MockResult[]
is returned, this has the same effect
as returning
new MockResult[] { new MockResult(-1, null) }
SQLException
- A SQLException
that is passed through
to jOOQ.Copyright © 2019. All rights reserved.