pullp
I do unit testing via Visual Studio Testing. I use code generators to generate the base classes for my modules, and the code generators output unit tests for the code as well. I use a database-driven test to check all the database input/output code. This helps to make sure any changes to the save/get code don't break existing code. I've written about this process in a 'code project' article before - it's pretty easy to find.
For a UI testing setup, I tend to load up my module in a solution by itself - with the main module (including .ascx and .ascx.cs files), the data provider the only projects in the solution. I write a short .cmd file which copies the relevant files (.dll, .css, .jpg, .ascx, .js etc) across to the correct location in the local dnn install. So then, you build your solution in vs, run the .cmd file (if you get excited you can make the .cmd file run as part of the build), and then attach the debugger to asp.net.
This setup saves having to load the entire solution into vs and speeds up compile time considerably. You just set your breakpoints and the code should hit and break them.
Note this all applies to a PA style module development, which, IMO, is more difficult but infinitely worth it in terms of version control and deployment. Putting code into app_code directories is easy to develop but much hard to control as a deployment.