Trying out TDD

I started developing a hobby project at home to try using TDD.  I pretty quickly came to an issue.  The app needs to store and update information in the ApplicationData directory.  I want to unit test this functionality, but I don't want it mucking with my files on disk from when I last used the app.

When I first hit this I resolved it by rewriting some code that shouldn't have been hitting the disk anyway and using an in-memory buffer to test that serialization works.  However at some point I did actually want to test that the information gets correctly persisted to disk.

The solution I came up with for this case is to use RunAs to run NUnit-gui as a different user.  I created a Tester Account on my machine with limited access and added to the TestFixture for the class that writes to disk a [TestFixtureSetUp] method that throws if the user is not my special tester account.  If I run NUnit in a different account the tests that touch files simple won't be run.

Comments

• Anonymous
  June 13, 2004
  As you have just experienced, that answer to nearly any TDD question is "Decouple". You decoupled your business logic from file IO.
  
  You seem to have had the (very common) experience that this makes your code nicer ("should have been hitting the disk anyway").
  
  I'd enjoy chatting with you more about ways to test the serialization code.
• Anonymous
  June 14, 2004
  I think everyone runs into the situation where they are going beyond the "unit" to do unit testing (link). We have a bunch of unit tests for business functionality that hits the database just because it was easier to write. This ends up makin...