On Fri, 2008-09-05 at 14:00 -0400, Joly, Robert (CAR:9D30) wrote: > > I have nothing against this proposal but if your immediate goal is to > become capable of seeing responses for the purposes of executing your > unit test, I would suggest that you look at the SipOutputProcessor > capabilities that got added to the sipXtaklib (and part of the main > branch). This allows an observer to be notified every time a request or > response is being sent by a SipUserAgent. I have relied on this > mechanism to execute unit tests that required the test code to see the > responses.
Very clever, but there is one additional benefit to doing it the way I originally intended (and then later messed up)... that is that you never actually have to call SipUserAgent::start, which means that the unit test never creates any clients, opens any ports, or starts the SipUserAgent thread at all. This constrains what you can test, but the constraints are all within the intent of this structure. I've found that it's much easier to make unit tests run smoothly and predictably if you avoid starting threads for low-level services whenever possible. In fact, I usually try to structure code within a component so that the functional bits (the stuff you can unit test) is in a method that doesn't rely on a thread having been started so that it can be tested standalone. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
