Когда нам нужно было выполнить модульное тестирование функций CF, которые опирались на объекты Java (которых мы сделали МНОГО), мы использовали Mockito для насмешки объектов Java.
Итак, надеясь, что этофрагмент кода имеет смысл, с тех пор, как я это сделал, прошел почти год:
<cfcomponent displayname="TestWhatever" extends="mxunit.framework.TestCase" output="false">
<cffunction name="setUp" access="public" returntype="void">
<cfscript>
// named it mk for keeping it short
variables.mk = createObject("java","org.mockito.Mockito");
//Create the mock object
variables.mockNote = mk.mock(createObject("java","com.company.whatever.note").getClass());
// Mock Data
fullList = {whatever listNotes() returns}
partialList3 = {whatever listNotes(3) returns}
//some common mocking
mk.when(variables.mockNote.listNotes()).thenReturn(fullList);
mk.when(variables.mockNote.listNotes(mk.eq(3))).thenReturn(partialList3);
mk.when(variables.rootOrgObj.guid()).thenReturn("root");
// Assign the mock object to where your CFC expects it.
instance.note = variables.mockNote
</cfscript>
</cffunction>
</cfcomponent>
Сказав, что, если ваша функция семпла реальна, нет смысла ее модульное тестирование.Это просто ничего не делает, но является прокси для объекта Java.Там нет существенной логики для тестирования.
Так как у вас есть значение по умолчанию для cfargument, оно всегда будет существовать (опять же, я думаю, это был год, так как я сделал CF), так что вашоператор guard даже не требуется - всегда будет вызываться первый путь кода, с переданным maxCount, если он указан, или с 9999, если нет.