I try to use TDD as much as I can. When I do, I stowe all comunication with the outside away in wrapper classes. A few minutes ago, I made a wrapper for the static class Directory, so I can test my other code without talking to the actual file system.
But what about unit testing the wrapper itself? Since I use TDD, it nags me that I haven't written tests for it. On the other hand, It is a wrapper and nothing else, so do I really need to?
I tend to do the same and not worry about unit testing wrapper classes, as long as I've satisfied myself that they contain the bare minimum amount of code. If, as in your case, I were calling a number of methods on the Directory class, I'd create an interface containing each of the methods I'd be using to ensure that I'm able to test as much of the behaviour of my system under test as possible.
As long as you are using integration and/or acceptance tests as well, it's fine not to unit test your wrapper classes directly. If you try to test Directory directly it's an integration test anyway. I would ask myself whether I had an automated test at some level that would fail if I were to remove the interaction with the Directory class from my code.
Bear in mind that the reason you're normally forced to write wrapper classes is because the code you're trying to test is not inherently testable and is a dependency that cannot be mocked out. Creating the wrapper class allows that behaviour to be mocked out.
