Should I be unit testing this class?

Answer 1

The only thing that I can see is making sure you get out the handle that you put in via your constructor. I know that it's obvious that you implemented it this way, but a test would assure you that it stays this way. I would test this only because you are injecting it via the constructor. If it was just { get; set; } I probably wouldn't.

 [TestMethod]
 public void ConstructorTest()
 {
      IntPtr handle = new IntPtr(100);
      MapinfoWindowHandle winHandle = new MapinfoWindowHandle(handle);
      Assert.AreEqual( handle, ((IWin32Window)winHandle).Handle );
 }

Answer 2

The pragmatist in me says no, because the class does "nothing", so there is "nothing" to test. But sure you could still test it, just for documentation purposes, and as a contract for future developers.

Answer 3

GUI code is notoriously hard to unit test. I've never found it to be too useful in my own applications. Just keep your business logic out of your GUI so you can easily test that. I generally test the gui code with with either manual or automated integration/acceptance tests. It's hard to write a test to verify that something "looks right."

Answer 4

I'd certainly test for trying to construct it with a NULL (0) or INVALID_HANDLE_VALUE (-1) and probably have it throw on either/both if appropriate (it's unclear if it's ok to initialize the class with an IntPtr.Zero, but it's almost certain that a -1 would be invalid.

Answer 5

Yes. If a class is worth writing, it is worth testing

Answer 6

Yes write the test. If later someone changes the code or adds some new code to it, you have at least one test to make sure the class works as it was intended to.