views:

393

answers:

4

I'm looking into adding some unit tests for some classes in my data access layer and I'm looking at an update routine that has no return value. It simply updates a row based on the id you provide at whichever column name you provide.

Inside of this method, we collect the parameters and pass them to a helper routine which calls the stored procedure to update the table.

Is there a recommended approach for how to do unit testing in such a scenario? I'm having a hard time thinking of a test that wouldn't depend on other methods.

A: 

I would just use a lookup method to validate that the data was properly updated.

Yes, technically this would relay on the lookup method working properly, but I don't think you necessarily have to avoid that dependency. Just make sure the lookup method is tested as well.

Eric Petroelje
A: 

I would use the method to get that data and check the return value to what you updated and Assert the expected value. This does assume the method used to retrieve the data has been tested and works correctly.

CSharpAtl
+2  A: 

Test the method that reads the data from the database, first.

Then you can call the update function, and use the function that was tested above, to verify that the value that was updated is correct.

I tend to use other methods in my unit tests as long as I have tests that also test those that were called.

If your helper functions are in the database (stored procedures or functions) then just test those with a DatabaseUnitTest first, then test the visual basic code.

James Black
A: 

I use nhibernate and transactions and for unittests I don't commit to the database but I flush the session which gives the same errors if needed but doesn't write the data.

Of course if you have a build server you just run the unittests against a freshly made database which is freshly made on each build. Try using an filebased database like firebird or something.

chrissie1