LLB Testing Specification
Conner wrote a JooqMock
class to supplement our testing infrastructure for LLB's backend API, in addition to JUnit. In this documentation, we'll first explain the purpose of JooqMock
, followed by a rundown of its methods. Carefully annotated examples of how public JooqMock
methods would be used in a test will also be provided. See the JavaDoc for additional details.
Purpose
The purpose of JooqMock is to serve as a mock for testing database interactions, specifically CRUD operations (create/read/update/delete).
Examples of calls to all CRUD queries in our implementation are:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
void addReturn(String operation, Record record)
The addReturn method is used to add an individual record associated with a given operation. The record will be added to the queue of records that will be returned from the execute() method. In other words, it essentially adds the record that would be returned if we queried the database with the given operation.
1 2 3 4 5 6 |
|
void addReturn(String operation, List<? extends Record> records)
This overloaded addReturn method is used to add multiple records associated with an operation to a list of records to the queue of records returned by the execute() method. The hashmap that stores the records to return by execute() separates the output by operation, so all of the records given to this method would be the result of querying the database with the given "operation" multiple times.
1 2 3 4 5 6 7 8 |
|
void addReturn(String operation, Supplier<Result<? extends Record>> recordFunction)
This is used if we want to add records with a Supplier that returns records. A Supplier is merely an interface in Java that helps support lambda functions, read more here. We've never needed to use this overloaded method before so there is no example, but it could be useful later.
void addReturn(Map<String, List<? extends Record>> records)
If we have a map from a CRUD operation string to the records associated with that operation, this method may come in handy by building our mock directly from that map.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
void addEmptyReturn(String operation)
Something needs to be returned each time a query is made on our mock, even if it's nothing. This method is a convenient way to say return no results the next time an operation is used.
1 2 3 4 5 6 7 8 9 |
|
int timesCalled(String operation)
Gets the number of times a operation was invoked on a mock.
1 2 3 4 5 6 7 8 9 |
|
Map<String, List<String>> getSqlStrings()
Get the strings associated with each respective SQL query called. Not used yet, but could useful for debugging.
Map<String, List<Object[]>> getSqlBindings()
Get the objects associated with each respective SQL query called. This is more compatible for testing than just plain strings, so we use this instead. You'll want to use this to test that the bindings on UPDATE operations are correct, to be specific.
1 2 3 4 5 6 7 8 9 |
|
int getId()
Gets the ID of the next record to be inserted. Not used yet, but could be useful for debugging purposes.
DSLContext getContext()
This method initializes the mock database when passed into the constructor of a real implementation.
1 2 3 4 5 6 7 8 9 10 |
|
MockResult[] execute(MockExecuteContext ctx)
Executes a query on the mock. Whenever execute() is called in the implementation in what would be for a real database, it gets forwarded to this method instead during testing.