· Aug 16, 2018


I need to start doing unit testing for some of my code.

Why does it delete the unit testing class from Cache when I run the test?

Is there a way to turn this off?

Discussion (20)3
Log in or sign up to continue


We're using UnitTesting for application validation for internal application development within InterSystems.  If you have any specific questions, feel free to create new Questions in the D.C. and tag me, or if you would prefer a general discussion you can ask your Account Manager or Sales Engineer to set up a discussion with me.

There have also been several Global Summit presentations which have touched on the topic - not sure if you've seen these?


Ben Spead

Manager, AppServices, InterSystems

The first half of that should be helpful.  Code coverage may be helpful too if they are able to move into a CI type BUILD infrastructure (I don't know how well Test Coverage would work in a more dynamic Dev environment as longitudinal history might be harder to maintain ... haven't really thought about that too much before...)

@Ben Spead @Evgeny Shvarov 

I watched the video, thank you!

As a new Cache developer, I'm curious to know if TestCoverage will ever be implemented in a future release of ObjectScript in the %UnitTest framwork versus why it stands alone as in InterSystems developed OpenExchange project.

Still learning the differences between Cache, ObjectScript, all the InterSystems' applications and how it all intersects with what my company has been doing in Mumps for the past 30 years.  

If I can reel back to some basics, however.  Because I never really written a complex applications, my sense of testing as always been "write a little, run it, write a little run it," and usually that was in Java.  It was easy to write a driver class or main method to test the code and see what was going on.  I suppose in a more complex system that is always growing, you need something like this unit test framework to single out these classes to run without writing a separate driver class, or at least in this case TestManager is acting as that driver class.  Am I on the write track on how to think about this?

Thanks for everyone's help!


You are most welcome.  In terms of why TestCoverage was released on OpenExchange, it is something we have been exploring internally last year and wanted to share with the Community in time for Global Summit 2018.  In terms of whether or not it will actually make it into product, I can't speak to that but perhaps the author @Timothy Leavitt  can comment on that (I believe there were at least exploratory discussions with Product Management on this topic).

Exactly!  We are actively using it internally within InterSystems - both in internal application development, and in HealthShare product development.  As discussed in the video we have found incredible value in this tool for decreasing technical debt (and making sure new changes don't add to it).  We thought customers might find the value in it as well.  

Hello Mike, yes we have figured out how to implement unit testing in Cache. It's an excellent way to test all cases. But for the type of current work we are doing (reporting), it might be too much work. Once you get the hang of it, it's a pretty simple process. It's up to you to cover all of the test cases.

If you need help, you can just post your question here. There are a lot of Cache experts in this community that can help.

Thanks @Roberto Cahanap 

The catalyst for my initial post was simply reading the package and class documentation for %UnitTest.  I noticed that whoever set up our unit testing framework here was only using the %TestCase class and %Manager class.  There are many other classes in the package, and I'm trying to get a sense if we are utilize the tools in the package to the greatest extent.  

The other half of it is that I'm a very new programmer (brand new pretty much) and I'm not accustom to unit tests.  I'm curious to know how others do it so I can see where's there common ground and where people differ.

I'm going to watch the presentation linked above and then get back with more questions.


The %UnitTest package is designed such that each suite stands alone: it is loaded, compiled, run, and deleted, independent of any other suite. Deleting the test classes is just part of cleaning up.

You can pass the /nodelete qualifier, or even set it as a default using $system.OBJ.SetQualifiers(). Given that deletion is the default behavior, however, I suggest that you adjust your workflow accordingly. I edit XML export files directly. Some people maintain a development and test namespace, with the classes being exported from development, and imported into test.