Rubberduck needs to FAKE ALL THE THINGS!

[comintern]

Rather than having separate issues for each VBA function that needs to have an IFake implementation, this meta feature-request should be used to track and prioritize functionality that needs to be faked. The PR with the framework shouldn't be much longer, so it's time to start tracking these. In general, we should probably prioritize functions that disrupt unit tests (like MsgBox and InputBox) so let's get those covered before adding more to the list. Note that the vbe7.dll doesn't have all of the type hinted variations, so just list the Variant version.

If you implement one of these, check it off. If you want to add a new one to the list (and have the permissions to do so), edit this comment.

TODO:

Interaction

• MsgBox
• InputBox
• Timer
• Beep
• DoEvents

File system

• Kill
• FileCopy
• MkDir
• RmDir
• Dir
• ChDir
• ChDrive
• CurDir
• EOF
• FreeFile
• FileAttr
• FileDateTime
• FileLen
• GetAttr
• SetAttr
• Loc
• LOF
• Reset
• Seek

Registry \ System

• GetAllSettings
• DeleteSetting
• GetSetting
• SaveSetting
• Environ
• IMEStatus
• Now
• Date
• Time
• SendKeys
• Shell

Misc

• Rnd
• Randomize
• VarPtr
• ObjPtr
• StrPtr

[retailcoder]

Should CurDir be implemented with ChDir changing its return value? Or that's for the user's setup code to do? How does .Returns(CurDir) behave?

[comintern]

@retailcoder - I was thinking of building a complete mock filesystem to attach when any of the file handling functions were faked. Maybe in its own namespace? Something like:

Fakes.FileSystem.CurDir.Returns("C;\Foo")

Maybe with it's own configuration. Could probably do both too - allow the above and the option to do:

Fakes.CurDir.Returns("C:\Foo")

[retailcoder]

@comintern that. we should mimick the standard library's structure, so MsgBox would be under Fakes.Interaction.MsgBox for example.

How would mocking, say, a Worksheet or a Range object work?

[comintern]

@retailcoder - It depends. For COM objects, EasyHook needs an instance to examine the interface for. IIR, the object itself is always going to be a parameter on the interface call so we could either tie them to specific user created objects or try to emit a managed class that implements the passed interface. It basically needs some more research.

[bclothier]

@comintern Could we just do a CreateObject of the application, dump stuff in the temp folder and then delete once done? That way, Fake is dealing with a dedicated instance of Excel/Word/other Office application, and thus would model its behavior much more accurately than an actual Fake implementation.

This isn't a general solution, though because that makes assumption that there's an Application object that we can instantiate and configure to use the Temp folder for the rest of testing. Not all COM objects have that design model but for a complex object model like Access or Excel, I'm more liable to want just to use a new instance of that application and let it do its own thing than finding runtime bugs that wasn't caught by the fake implementation.

[comintern]

@bclothier - Maybe, but most likely not. I'm guessing the rtcCreateObject is just a thin wrapper around the VBA CreateObject function. If RD was hooking that and just newing up an object to mock the interfaces on, we might as well just use the existing objects. The other downside would be that anything we do inside a unit test that potentially creates new document objects probably isn't handled very well currently (IIR we're currently not disabling the parser if code is under test). Hooking the specific interface would allow mocking individual members (for example Range.Value), but leaving the native functionality in place for everything else. I think ultimately it should come down to a design decision as to whether to replace a specific interface member of a native object or set up an entirely managed dummy interface.

[bclothier]

@comintern, well, I wasn't thinking of just a straight CreateObject anyway. As I alluded to, additional configuration would be necessary so that it works in the temporary filesystem and maybe even use RD's eventual fake filesystem. As part of the CreateObject build-up, you can configure RD to ignore that dedicated instance of Office application for testing, among other things.

The point is that I think it's easier and less buggy to extend the existing native objects than to supersede it with a entirely new fake implementation, at least for those within the Office applications.

Two specific cases to think about:

ActiveWorksheet or Screen (bleh) are good examples. After discounting the abuse of thereof, thanks to Macro Recorder, suppose we have an add-in that should operate on the current worksheet. Still, I know there has been many buggy VBA procedures that makes wrong assumption about what is the active worksheet. but there was other code that changed the active worksheet, and thus the code fails to operate on the expected worksheet. That would be very difficult to consistently replicate in a fake implementation. There are several other Activeobjects in various Office application. Selection, too. I sure don't want to try and fake those.

SaveAs or Close are other good examples - those have several side effects that should be replicated -- firing events, changing the state of the application, etc., etc.. We certainly do want to override those methods and ensure the paths for saving the document are routed to our temporary or RD fake's filesystem, but we should then let those run using the native object's model so that we can observe all the side-effects and thus determine accurately if our test should pass or fail.

Finally, because those stuff are quite tightly coupled, I don't think it's all that practical to set up dummy interface on a case-by-case basis. You'd end up needing to build interfaces for all exposed objects within that application's object model, I'd think.

[comintern]

@bclothier - That's basically what I meant by "I think ultimately it should come down to a design decision as to whether to replace a specific interface member of a native object or set up an entirely managed dummy interface". RD shouldn't be in the position of determining the best methodology for test implementation - that is the domain of the test writer. What RD can do is offer a tool-set for the test writer to choose from. If the system under test only calls one method on an interface, you might not even need a native object at all. At the end of the day, if test setup is difficult, refactor in a way that your code is testable. If the test setup is impossible (like this feature 😁), that's just an eventuality that you deal with as well as you can.

Ultimately, this will probably come down to "functionality that is easier to code will be offered first, followed by stuff that is difficult to code". 😉

[ThunderFrame]

I think the Global enumerable collections would be good candidates for Fakes.

Set v = Fakes.Excel.Workbooks("Foo.xlsm")
Set x = Fakes.Excel.Worksheets("Settings")
Set y = Fakes.Excel.Sheets("Report")
Set z = Fakes.Excel.Addins("Foo")