Ignore BREAKs

Use BREAK with a postcondition depending on Username 
or some other personal switch (eg. PPG)

If you have just a few breaks, one of the possible solutions has been given by Robert Cemper. In case, you have tons of those breaks, you could execute the unit test in background:

job ^performUnitTest

assumed, your unittest can work in background and all the output goes, for example, in a file.

The solution for the case you let run the unittest in a terminal session, could be something like this

do turnOffBreaks, performUnitTest, turnOnBreaks

The only problem is, to turn breaks off (or on), you need one view command, one $view() function and one $zutil() function (to get the right address for the view-s). Unfortunatelly, the use of the above tools is discouraged, so your best bet is, to ask WRC for a help.

That's one of the very good reasons, do not work together on the same server. So, yeah, the best way to go is to use your own instance, so, no one will break your tests excepts you

It might be easier just to always make your BREAK commands conditional like (Robert Cemper suggests above).  Do it like:

    BREAK:$GET(^|"USER"|MyNameBreakAppEnable)

Use your own name for "MyName".

Then you do SET ^|"USER"|MyNameBreakAppEnable=1 to enable break points and
KILL ^|"USER"|MyNameBreakAppEnable to turn break points off.

Change the name of "App" to conditionalize break points for use in different applications.  And "USER" is a scratch namespace available on all the instances you plan to do debugging on.

Discourage the use of hard coded breaks in the first place! There are alternatives.

• Use ZBREAK Tag+OffSet^Routine to set a break point just for the current process
• Use the debugger in Cache´ Studio (under the Debug menu and attach to a process)
• George James has a decent debugger in Serenjii
• Put something in your processes to remove hard coded break points when you promote code through the development cycle (you can automate this if you try)