My code interacts strongly with its environment. Should I bother to unit test?

Code I'm working on collects performance data (eg CPU usage) from the operating system. I'm wondering if I should bother to attempt to unit test this code. It seems that to unit test code, you need to design code that is isolated into units. My code is so closely tied to the OS though that if I isolated the code out that interacts with the OS into a wrapper that I could mock out, there wouldn't be much left to test.

So, I'm thinking unit testing won't work here. Am I misunderstanding how I should use unit tests? Everybody in blogs I read preaches that they're good, but I'm not sure they're useful for all application domains.

Eg, if I move this code to a different version of the OS, I'm sure there will be lots of bugs, but I can't see how unit tests could help me find them.

Have you found the same problem? Should I even attempt to write unit tests for this?

From stackoverflow

• Do you have any business logic? Calculations? or are you just grabbing and displaying data?

  Unit testing is useful for, well, testing units. In other words are the any parts of you app that can work in isolation? If not, then theres not really anything to unit test.

  Functional tests are another story...

• The outcome of your application is performance measuring but are you sure the metrics for performance are being measured correctly? This is where test driven development shines. Your forced to write code that you know to work logically, then when you run the application you can be significantly more confident your measurements are correct if all your tests had previously passed.

  Test driven development TDD is fast gaining grown and is one of the components of XP (Agile) that seems to really be picking up momentum. Its worth looking into.

• Sounds like you could benefit from some basic tests, like: "Does this entire module squirt any out any data when I port it to another operating system?", but beyond that, be pragmatic.

  If doing it doesn't actually help you, don't do it. Tests for testing sake is an easy way to waste time to little avail.

• I find it hard to believe that anyone can write code without using procedures or methods or blocks of code that can be turned into procedures or methods. If you can do this, then you can write tests for those methods. The process of writing those tests will almost force you to write cleaner, more decoupled code than you would otherwise. If your methods are tied to kernel data structures, then writing tests for your methods will force you to abstract away from those data structures for your logic and write thin wrappers around them. You may not get to the point where every bit of your code is fully tested, but I think you will find -- especially if you start by writing the tests first as @Wambie suggests -- that you will be able to test more than you thought possible and your code will be the better for it.