1

I am implementing an interface into a C# class, whose entire job is basically just to call some T-SQL stored procedures and return the data. Other implementations of the interface may obtain data through web-services, reading files, etc, so to test this particular class I'd ideally mock an SQL Server database and its procedures.

I'm not sure if this is feasible. I've seen tools like RhinoMock used to mock database tables but since the entire purpose of my code is to talk to a DB, can I mock the entire DB or is that a bit of a waste of time? I'd ideally like a way to transparently provide a replacement for having a real DB so local testing can be done, making real stored-procedure calls against a fake DB.

Mr. Boy
  • 60,845
  • 93
  • 320
  • 589
  • Are you sure @inquisitive_mind? It would be ideal but: http://stackoverflow.com/questions/3335162/creating-stored-procedure-and-sqlite – Mr. Boy Mar 10 '16 at 15:05
  • @montewhizdoh you might be right! – Mr. Boy Mar 10 '16 at 15:25
  • I think it all depends. You truly do not want to write unit tests that eventually end up testing code other than what you wrote. Testing to see if a connection works kind of falls into this gray area of "am I testing SQL Server, or am I testing my code?" and "am I using the correct connection string?". Best to ask: what code paths are there, incoming and outgoing from the stored proc? Are the tests copacetic with functional use cases? If you are TDD, you want to be closely aligned with the functional use cases - at that point everything will start dovetailing very nicely.. – code4life Mar 10 '16 at 15:46

1 Answers1

0

If you are building unit tests then you should not execute the stored procedure and you should stub this interface.

If you are building integration tests then you must have it all working.

In both cases your class shouldn't do it directly, you should have an inner handler like IDbHandler and during your unit tests you should mock it and during the integration tests you should use your concrete implementation.

The purpose of having a mock is to verify that the other side (DB in your case) got a request with the expected parameters but a physical component can't be mocked so just by adding an interface between your code and the physical component will enable those validations.

BTW I would start with having the unit tests and just afterwards add the integration tests.

Ɖiamond ǤeezeƦ
  • 3,223
  • 3
  • 28
  • 40
silver
  • 1,633
  • 1
  • 20
  • 32
  • So in other words, one does not unittest the class that you created to implement an interface you introduced to abstract the stored procedures. – Maarten Mar 10 '16 at 15:21
  • 1
    I'm not sure of the value of unit tests here. If the class is just supposed to call sprocs, you just want to make sure the sproc name and the named parameters all match up with what's in the DB. Seems that's the main value in testing this concrete class. – Andy Wiesendanger Mar 10 '16 at 15:21