Slashdot Mirror


Debugging Asynchronous Applications?

duncan bayne asks: "I'm attempting to debug a complicated telephony application, written in C#, that's almost entirely event driven. This is the first time I've debugged a large asynchronous application that isn't a GUI, and I'm curious to know what advice the Slashdot crowd has to share - have you any recommended tools, best practices, or common pitfalls to avoid?"

2 of 78 comments (clear)

  1. Mock Objects by kevin_conaway · · Score: 2, Insightful

    The question is kind of vague. Are you debugging receiving events? Sending events? Both? I'd look into Mock Object and see how they can help simulate asynchronous environments.

  2. The usual rules apply by jd · · Score: 2, Insightful
    Design from top down, test from bottom up. The lowest-level components won't care how they're called, only that they're called with the right parameters. That, alone, won't be enough but will give you a good starting point. Test harnesses can also be used, as they can simulate events.


    Look for invariants and ensure that they hold true where they are supposed to. That doesn't require fine analysis, but will detect problems in the logic when you're running the full system. Use profilers and coverage analysers to make sure that when you DO do invariant checks that you're actually checking all the areas they're supposed to hold up.


    Test "normal" values, borderline/extreme values (that's where overflows, underruns and other assorted nasties are likely to show up), and completely erronious data. Borderline can include borderline values, but since this is a network app, it can also include extreme volumes (very little or vast amounts of traffic, or even massive variations). Erronious data can be data that is invalid in and of itself (malformed packets, for example), or data that has no rational meaning (a non-existant codec, or a value that decodes to something absurd - I doubt many people will be doing 11.1 audio streams for VoIP, for example!)


    Beyond that, it's all much of a muchness. There's very little that is async specific to testing, so long as you concentrate on the logic rather than the means of getting there.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)