Question

I have a sp called MoveSomeItems which gets some rows from tableA from Foo Db. and moves them to tableA in Bar Db.

I want to test this sp if it really moves the items.

Is it enough to run this sp in a transaction and select the rows to see if they are moved OR I should approach it in a different way?

Answer 1

This depends upon what the impact of it all going wrong is? What impact would having incorrect data in the destination table be, will it kill someone, simply annoy them or is it unlikely anyone will notice? Will it be easy to fix?

There are risks associated with the approach you have given. For instance:

1. If the database is very busy, it is possible to cause excessive locking or even a deadlock with a transaction that may cause other transactions to fail. Setting the TRANSACTION ISOLATION LEVEL to READ UNCOMITTED and the DEADLOCK PRIORITY to LOW will help to minimise this but not eliminate it entirely.

2. There is the possibility that other transactions may be running in READ UNCOMMITED isolation mode. In which case they will see the results of the insert temporarily until the roll back is issued.

3. It is worth noting that if the procedure you are testing calls COMMIT TRANSACTION inside it you might not get the result you want when you call the ROLLBACK.

4. You might push the database or log to run out of disk space.

5. You might use up all the available CPU, Memory, Disk IO, Network or some other capacity limit.

6. Finally, I suspect this is not a complete list. The point I’m trying to make is that it could go wrong in strange ways.

If you have a personal development database that is fully backed up then you wouldn’t even need the transaction, simply do a restore after the event. The transaction may well save you some time though. This is the safest solution.

If you are using a shared development database your approach might be acceptable enough, but I would still do a backup just in case, especially if you are already on bad terms with the team.

If you are using a live database it may still be acceptable if the system as a whole is not that critical and can sustain some downtime while you repair things. Again do a backup.

If the database you are looking at is controlling a process that is safety critical or some other mission critical function, don’t even go there you may lose the no claims on your liability insurance or worse. In this instance it is best to restore a backup onto a test server and test there thus creating my first scenario. But be warned there are lots of issues that have to be considered when doing this. For instance it may be illegal to use personal information in a test system. Also there may be dependencies on other systems that will need to be mocked out to ensure you don’t affect them, for example don’t connect a test system to a live email server.