Reputation: 6998
I'm starting to get into unit testing more. I have a project where Excel is the "engine" and it can't be taken out (at this time). I need to provide the workbook with various inputs, run a macro in the workbook, and then collect the results. It's a huge nasty workbook so taking anything out of it isn't an option right now.
So given that the main dependency is Excel.Interop objects, how do I setup unit tests where almost all the code is hitting Excel?
Upvotes: 4
Views: 2800
Reputation: 152576
In theory, "unit tests" should test as little as possible, with as many dependencies mocked as possible. With Excel that may be very tricky if not impossible.
Ideally, I would think the tests would be:
That takes Interop out of the picture and lets you unit test those pieces separately.
Putting it all together is more of an integration test (which are typically not automated) that a unit test.
Upvotes: 4
Reputation: 6304
That's going to be tough. One way to start is just add another level of abstraction. Make a wrapper around the excel dependency then mock it out.
That sounds like it wouldn't buy you much in your case, since you say it's really nasty. It sounds like you have a lot of refactoring to do.
Upvotes: 0