New post
AllAccepted answers
Timothy Leavitt · Mar 11

Hi Fiona,

My team maintains Embedded Git (our preferred name for git-source-control these days). I'm happy to help set up a call with my team to discuss your needs further.

To hopefully untangle things a little bit:

Embedded Git supports multiple developers using a shared remote development environment - that's one of its main purposes. The role of an embedded source control extension in IRIS is to keep the filesystem in sync with the IRIS database, reflecting IRIS-level edits through any IDE or the management portal on the filesystem and pulling filesystem-level changes (e.g., those caused by git commands) into IRIS. Given that there is only one location on the filesystem that is tracked, there is a general, reasonable limitation that a namespace can only be tied to one branch in a single repo at a time.

IPM use in this setting is probably rare; and if you are using it, you're most likely not using a shared remote development environment. In the IPM use case, the package definition provides additional information about which repo/folder a given unit of code (say, a class) belongs to, which means we can import/export from different repos which may shift branches independently. This is a powerful tool for building a more modular codebase, but the additional complexity means that it's better suited for local development where everything is under the individual developer's control.

To support users working in different feature branches, a common approach is to give each user their own namespace on the shared, remote development environment, and we provide tooling ("basic mode") around orchestrating promotion from feature branches to a "main" branch associated namespace via merge requests in your Git remote.

Re: files in the baseline, this might just be a bug. What is your mapping setup (in Settings)? Did you map the web application your interested in?

Best,

Tim

Timothy Leavitt · Nov 4, 2024

@Jani Hurskainen providing a top-level answer here:

If you want to truly build your own unit test framework from scratch, you'd need to create a custom resource processor class in IPM. I see from https://github.com/intersystems/ipm/issues/616 that you've already discovered this feature and I appreciate your tenacity and the deep dive into IPM that you're doing.

Every development team I've worked on within InterSystems (that is, three very different ones) has had its own things it's wanted to do that %UnitTest.Manager and %UnitTest.TestCase don't *quite* do the way we want, with the API we want, right out of the box. The approach in general is to extend %UnitTest.Manager to tweak unit test runner behaviors (IPM does this itself, as you may have noticed); to extend %UnitTest.TestCase to add application-specific utility methods, assertions, and generic On(Before|After)(All|One)Test(s?) implementations (often controlled by class parameters); and potentially to add some mix-in utility classes that one might extend along with %UnitTest.TestCase or your own derived unit test base class.

For the basic case of "I want to run tests with my own %UnitTest.Manager subclass" we have a flag you can pass in to override the unit test manager class, -DUnitTest.ManagerClass=yourclassname. See https://community.intersystems.com/post/unit-tests-and-test-coverage-int... for an example of how to use this (with my team's https://github.com/intersystems/TestCoverage open source package).

At the IPM codebase level, there's special treatment of the common "pParams" array passed around everywhere - something looking at pParams("UnitTest","ManagerClass") will find the value specified in -DUnitTest.ManagerClass in the package manager shell command.

Hopefully this is helpful!

Timothy Leavitt · Nov 4, 2024

@Evgeny Shvarov to some extent we already do, via the -DUnitTest.ManagerClass parameter we use to run TestCoverage and through custom resource processors (which I see @Jani Hurskainen is already playing with!)

The common pattern in ObjectScript if you're going to customize unit test processes is to write a subclass of %UnitTest.Manager that does things the way you want. (And probably a few subclasses of %UnitTest.TestCase that add the standard assertion types, maybe some application-specific utility methods / wrappers, etc.) IPM will play well with this model, it's more work (all around!) if you want to write your own entire unit test framework from scratch.