Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

3 Answers

up vote 5 down vote accepted

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.

share|improve this answer
    
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 Jul 11 '12 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 Jul 11 '12 at 14:30
    
@aspdotnetuser: Right! Testable code is maintainable code. –  kevin cline Jul 11 '12 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 Jul 11 '12 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. –  Péter Török Jul 11 '12 at 15:38
show 1 more comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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