c# - Unit test multi thread environment with breakpoints in Visual Studio 2008 -

i having problem while debugging unit test in visual studio 2008. unit test uses system.timers.timer (within business logic) handle delay (1'000 miliseconds). thread running test put sleep 5'000 miliseconds.

when running test on own, passes. when running tests (>120) passes , fails (not deterministic). tried setting breakpoint in mock object, set flag asserted in unit test. when debug test on own, phenomenon, assert.istrue() fails quick watch tells me, true:

public class objectmanageraccessmock : iobjectmanageraccess {     public bool executecommandwascalled { get; set; }      public void executecommand()     {         executecommandwascalled = true; //set breakpoint here     } } 

does thread running test continue run, when thread stopped (through breakpoint)?

i suspect you're seeing while debugging side-effect. assertion fails because false, due threading concerns value true time view in debugger.

increasing timeout in test should solve problem, beware.

timers seem idea @ first can lead problems later on. environmental issues, such other executing processes or running tests on slower machine, drive how timers used. unfortunately, if increment timeout meet needs of slowest machine you'll end series of tests extremely slow.

rather use thread.sleep in test, consider looking @ ways make tests run fast code does. example, raise event on test subject when operation has completed.

[test] public void demonstratethatthetestrunsasfastasthesubjectundertest() {      var resetevent = new manualresetevent(true);       // configure our test listen completed event      var subject = new mytestsubject();      subject.oncomplete += (sender,e) => resetevent.set();       // perform long running asynchronous operation      subject.dolongrunningoperation();       // wait 10 seconds      resetevent.waitone(100000);       assert.aretrue(subject.operationcomplete); } 

in above, use manualresetevent block execution until set operation called. note supplying timeout value reset event operation doesn't run forever. if timeout exceeded it's our operationcomplete still false, test fails.

if want finer detail determine if test timed out, waitone method returns boolean indicates whether operation successful.

bool completedwithouttimeout = resetevent.waitone(10000); assert.istrue(completedwithouttimeout, "the operation timed out.");