Allow for late-binding of references

[mwolfe02]

In addition to

Private Assert As New Rubberduck.AssertClass

which requires a compile-time reference to Rubberduck and deployment of the dll with the mdb, I would also like to be able to do:

Dim Assert As Object
Set Assert = CreateObject("Rubberduck.AssertClass")

This would make it easier for developers to add unit-testing (and other Rubberduck functionality) to a project without having to needlessly complicate deployment for functionality that end-users will not see.

[retailcoder]

Yes, BUT then the Assert object loses IntelliSense/autocomplete. Not cool. I think it should be a configurable option. Like, a checkbox that says "Use late-binding for references to Rubberduck type library" in the settings dialog.

[rubberduck203]

Agreed with this, but I do think supporting Late Binding could alleviate the pain caused when upgrading to a new version of Rubberduck. As it is, the end user must update their reference to Rubberduck in each VBA Project that is using Unit Testing. I'm not 100%, but I think late binding would make it so that the reference doesn't need to be updated. Definitely should be a configurable item.

Other options include trying to update the the reference prior to running the Unit Tests or an Option to refresh the reference via button click.

[retailcoder]

Should we have a separate library to expose the IAssert interface / AssertClass implementation? That thing isn't likely to change anytime soon... Perhaps a RubberduckUnitTesting.dll + RubberduckUnitTesting.tlb?

[rubberduck203]

Yes. And any other future exposing of code to COM should be in a separate *.dll. Something like RubberduckLibrary.dll. This will allow user to reference either Unit Testing, or Library code without there being too much clutter.

[mwolfe02]

@retailcoder , I should have been more precise in my original request. I would like to see both early-binding and late-binding supported.

My code would then look more like the following:

Dim Assert As Object  'Rubberduck.AssertClass
Set Assert = CreateObject("Rubberduck.AssertClass")

While I was actively developing my tests, I could add the reference and change the first line so that I got intellisense:

Dim Assert As Rubberduck.AssertClass
Set Assert = CreateObject("Rubberduck.AssertClass")

Then, when I was done, I would remove the reference and return the first line to

Dim Assert As Object  'Rubberduck.AssertClass

so that it would compile on machines that did not have the required dll. But I would still be able to run all of the tests without needing an explicit, early-bound reference to Rubberduck. Make more sense?

[rubberduck203]

Makes sense to me @mwolfe02.

It would also be nice to document how this is done after the change is made. Thank you for the clear cut example.

Another option would be to use a project level compiler directive to conditionally compile the code.

#IF DebugMode #Then
    Dim Assert As Rubberduck.AssertClass
    Set Assert =  CreateObject("Rubberduck.AssertClass")      
#Else 
    Dim Assert As Object
#End If

[rubberduck203]

@mwolfe02 I'm not sure if you're following this issue still, but it has been fixed in the master branch and will be included in the v1.2 release.

We just needed to declare a ProgId for the class.

[mwolfe02]

That's great news. I'll have to play with the v1.2 release. Keep up the good work.

[rubberduck203]

Thanks @mwolfe02. Keep the bug reports coming. =;)-

Also, I've given it some thought and given the tests are stored in modules, rather than classes, you'll need to create a new AssertClass in each test method. So, conditional compilation may be the best way to implement what you would like to do.

I've not tested that method, so please let us know how things work out for you.