Home/ Questions/Q 564329
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T12:45:18+00:00

I have an ExcelReader class in my C# application – I need to import

  • 0

I have an ExcelReader class in my C# application – I need to import Excel spreadsheets into database tables. My problem is that this is one of the few untested classes – I cannot use a “mock input” for it, and testing with an actual Excel spreadsheet makes the test a bit slow (about one second). I know the class is working correctly – I tested it manually – but I am a bit uneasy about leaving it without its own tests.

So – my question is: which one is better: no unit tests, slow unit tests, or a third way I cannot figure out?

[Edit] A lot of great answers, I’m really sorry I can only mark one.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    How about this?

    ExcelReader --- has --- ExcelInterop (interface) --- to read --- .xls

    I’m assuming that ExcelReader has more logic than calling Excel Interop Library functions.
    If that is the case, write fast unit tests for ExcelReader by slotting in a mock implementation of the ExcelInterop. You can use this to mock/stub calls to the interop library.

    Next write contract tests for the ExcelInterop interface. The test subject here would be a wrapper class (the real interface implementation) that delegates to the actual MS Excel interop assembly. These tests should verify that the APIs that you use work as you expect it to ; run this against a golden/reference .xls

    Mark the second group of tests with a ‘LongRunning’ or equiv attribute and run them less frequently (on the build machine/once at EOD) if they are too slow.

    • 0