2

I have a function in my VBA code which takes a recordset as an argument and I want to write a test for it without having to access the actual database.

Any ideas on how I would go about this?

Private Function GetAssignData(ByRef rst As DAO.Recordset) As AssignData
    'Set up our details
    iTeam = 0
    iPerson = -1


    With rst

    ABC_ID = .Fields("ABC Inventory ID")
    PROD_OP_ID = .Fields("Prod Op Type ID")
    INTEG_OP_ID = .Fields("Integ Issue Type ID")

'
'DO ALL OF OUR REALLY REALLY IMPORTANT LOGIC HERE
'

    'Assign Integ Tickets
    If .Fields("Ticket Type ID") = 1 Then
        iTeam = 2
    Else
        iTeam = 1
    End If

    'Assign Prod Ops Tickets


    End With

ReturnAssignData:
    'And send our final data :D
    GetAssignData.iTeam = iTeam
    GetAssignData.iPerson = iPerson
End Function
Ethan
  • 2,754
  • 1
  • 21
  • 34
  • Sounds cool. Post the code for the function, and what you've tried so far. – Smandoli Apr 08 '14 at 20:30
  • You can use a "disconnected recordset": either create one from scratch (http://stackoverflow.com/questions/10458418/in-memory-stand-alone-disconnected-ado-recordset) or use the "save to file" ADO funtionality to save a dataset after running a query (http://msdn.microsoft.com/en-us/library/windows/desktop/ms675273(v=vs.85).aspx) – Tim Williams Apr 08 '14 at 20:32
  • as a random alternative, what about selecting from the actual database into a temporary table (using the esoteric Access Select Into statement) then using that? That should provide the necessary structures quite simply without any further risk to the live data. No idea if this would be suitable – Cor_Blimey Apr 08 '14 at 20:59
  • @Cor_Blimey I could do that, but I could see it getting quickly out of hand as the codebase and test suite grows larger. Also, I want the ability to handle all of my tests within the code. It might not be possible, but I'm hoping it is. – Ethan Apr 08 '14 at 21:04
  • @Ethan that makes sense. Anyway, i'm sure it is possible ultimately as fundamentally, in the extreme if there is no syntactic sugar to it, it can't get worse than having to create a recordset on the fly e.g. the links Tim Williams linked. – Cor_Blimey Apr 08 '14 at 21:08
  • `without having to access the actual database` seems ambiguous. For one thing, comments are indicating it might be okay to do that. Also raises obvious approach of creating a dev set-up that uses a (truncated) copy of the actual database. – Smandoli Apr 08 '14 at 21:10

1 Answers1

0

What you could do is the following:

  1. Create an interface for the methods you use for the recordset. I wouldn't recommend trying to implements every method. The recordset is very large.
  2. Create a Mock recordset class that implements that interface.
  3. Within the Mock class reference the real recordset object. Your interface should then call the actual interface object.
  4. You pass in the mock object to your function.
  5. The mock object can call some callbacks that allow you to do whatever you want. You can also call the code that calls the recordset. This way the code goes into your mocking object separate from your production code. Note: I'd probably recommend using a function pointer callback for your code. Excel doesn't have the ability to do this. So you can create a delegate type c++ dll to do that and wrap it in some class. Alternatively there's an API callback you could possibly use called DispCallFunc.
PaulG
  • 1,051
  • 7
  • 9