I'm new to unit testing and I need some help with the following.

I have created a small project to help me learn how to make Unit Tests. The functionality for one of the forms in my application deletes a user from the User table (and other rows in mapping tables).

Currently, the unit test I have created to test this sets up the required objects and then calls the business rules method (passing in the user id) which calls the data access method to execute the stored procedure that deletes the rows in the tables.

Is this the correct method to test whether something is being deleted successfully? Should the unit test / setup method first insert some test data which the unit test then deletes?

3 Answers 3


IMHO if you are just starting to learn unit testing, it is better to leave databases out of the picture for now. Data in a DB is harder to test - in fact when you are testing code which makes direct calls to a DB, it isn't a unit test anymore but integration test.

You can unit test code manipulating a DB, but it requires more effort and tools, including extra frameworks - like DBUnit in the Java world -, interfaces, mocks etc. which are more advanced topics.

  • Thanks, my question probably seems very newbie-ish. I guess one of things I'm finding difficult is deciding even what to test! Hence why I thought testing data in the database wasn't a lot different to writing tests that assert values returned by methods etc
    – Theomax
    Commented Jul 11, 2012 at 14:28
  • 3
    And writing unit tests for the small project I created has made me realise that alot of the code needs to be moved into the business rules layer instead of being in forms code behind! This must be an example of one of the benefits of untit testing?
    – Theomax
    Commented Jul 11, 2012 at 14:30
  • @aspdotnetuser: Right! Testable code is maintainable code. Commented Jul 11, 2012 at 14:42
  • 1
    when you are directly testing a DB, it isn't a unit test anymore but integration test. Are you sure? If you're testing how an app works with a db, that's integration for sure, but unit testing a db is possible: blogs.msdn.com/b/atverma/archive/2010/07/28/…
    – StuperUser
    Commented Jul 11, 2012 at 14:45
  • 1
    @StuperUser, my phrasing was unclear, thanks for the feedback :-) What I meant was testing e.g. C# code which directly depends on (and makes calls to) a DB. Unit testing e.g. stored procedures inside a DB is a different topic indeed. I updated my answer above to clarify. Commented Jul 11, 2012 at 15:38

It will be much easier to write unit tests for SQL stored procedures in SQL. Take a look at tSQLt. Avoid retesting the stored procedures in your C# unit tests; take ratchet freak's advice and mock the database to test the C# code.


you should mock the (abstracted) database while testing the form

essentially providing a dummy implementation that does the minimum necessary to complete the tests

this way when you call submit on the form you can then see if deleteUser in the data access gets called

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.