31 October 2002

Finding thread states from the debugee while it is running Larry O'Brian has suggested a solution to my problem where I wasn't able to query the state of threads while they were running using ICorDebugThread. His solution is to use Process.GetProcess().Threads from managed code. I haven't tried implementing it yet to see if there's anything that the debugging services do that'll prevent this working but I'm hopeful that it should work. I'll try to implement it soon to see if it works. What other blogs are saying about this post. 5:07:09 PM    comment []  trackback []

Mono I'm going to install Linux and Wine at the weekend and give Mono a go with it's Windows.Forms support. As the classes get better implemented it should be interesting to see how well it all works in reality. At some time in the future I want to take a look at the mono debugger anyway as mine isn't going to work under Mono unless they implement the debugging APIs, which I think they should consider doing otherwise they're going to miss out on being able to run a chunk of developer tools if they don't. What other blogs are saying about this post. 2:05:04 PM    comment []  trackback []

The value of unit tests Unit Tests are a good thing. I concur with that statement!  I must admit, I have been half hearted with my unit test attempts in the past.  Mainly because I haven't put the time into arranging the pieces to make it happen.  But with my last project, one that involves multi-threading, I went in with both feet.  Do you know what I found?  I found I was able to move along much faster.  I felt confident with my code.  The code was better organized because when I wrote my tests the organization of code was centered around "units".  I used NUnit 2.0 and setup my VS.NET project with two targets one that ran the unit test and the other that ran my code in user mode.  I'm on my way to finishing this project but I can say that I will be using unit tests a lot more in the future. [StronglyTyped - Richard Caetano's weblog on software development] The problem has always been convincing people that unit tests do more than they sound like they do. It's hard enough convincing people to spend the time devoted to developing them in the first place since I think you need to have that first moment of relevation where you realise that your tests just saved you a great deal of time. This seems to be through either a refactoring or realising that the code you thought would work actually has had a great deal of things wrong with it that you wouldn't have realised until the bug reports started coming in. Not everybody here is convinced of their real value yet and it's very difficult to help them to realise what an advantage they are. You really have to reach that conclusion on your own. What other blogs are saying about this post. 10:27:22 AM    comment []  trackback []

Unit testing debuggers I've been writting unit tests for my debugger and it's not as evil as I thought it would be. I coded an event based system so the debugger application subscribes to the events that it cares about in actual debugger module and so I'm using console mode applications that subscribe to the events that they need to test the specific feature and then drive the debugger using a known executable. Most of the actual testing is performed by verifying that the events are returning the expected values. I'm not sure how changes to the CLR or OS will effect it, but for now it seems to be a valid way of testing. What other blogs are saying about this post. 10:11:36 AM    comment []  trackback []

© Copyright 2004 Jon Shute.