I’ve setup various methods to assert SQL behavior. With ORM, I ended up setting up a second ‘Unit Test’ database that gets reset between tests. This allows me to confirm a fetch operation returns the expected ‘42’ records and so on.
We’ve abandoned ORM development for front-end facing projects in favor of highly-turned SQL statements. Most of these test cases simply asset the SQL generated is as expected (since the SQL is dynamically generated by a DAO based on the arguments). Switching to just validating the SQL statement accelerated our CI builds by 40m!
Here is an example test case:
public void function setUp()
{
// Mocks
MockBox = new coldbox.system.testing.MockBox();
SUT = new platform.shared.models.DAOs.indexedDAO();
MockBox.prepareMock(SUT);
Q = MockBox.createStub();
qExecuted = MockBox.createStub();
qPrefix = structNew();
SlowCache = MockBox.createStub();
SlowCache
.$(‘get’)
.$(‘set’);
QuickCache = MockBox.createStub();
QuickCache
.$(‘get’)
.$(‘set’);
SUT
.$property(‘ApplicationContext’,‘variables’,‘production’)
.$property(‘QuickCache’,‘variables’,QuickCache)
.$property(‘SlowCache’,‘variables’,SlowCache);
}
public void function EPISODES_can_use_product_urlname_filter()
{
var expectedSQL = “select this from that were something = :else and so_on and so_on”;
// Results are ignored.
qResult = MockBox.querySim(‘this#chr(10)#1’);
qExecuted
.$(‘getPrefix’,{columnlist=‘asset_id’})
.$(‘getResult’,qResult);
SUT.$(‘getQueryObject’,Q);
Q.$(‘setSQL’).$(‘addParam’).$(‘execute’,qExecuted).$(‘setMaxrows’);
local.r = SUT.get(target=‘episode’,lid=4,allowPaging=false,filters=[{k=‘product_urlname’,v=‘photoshop-elements’}]);
assertEquals(expectedSQL,q.$callLog().setSQL[1][1]);
}