Timothy Leavitt · Apr 11, 2024 go to post

The answer about mocking is great.

At the TestCoverage level, by default the tool tracks coverage for the current process only. This prevents noise / pollution of stats from other concurrent use of the system. You can override this (see readme at https://github.com/intersystems/TestCoverage - set tPidList to an empty string), but there are sometimes issues with the line-by-line monitor if you do; #14 has a bit more info on this.

Note - question also posted/answered at https://github.com/intersystems/TestCoverage/issues/33

Timothy Leavitt · May 30, 2024 go to post

I like this in combination with a global mapped to %ALL that has:
^SYS("ConfigDatabaseOverride","BAR")="^^:ds:BARCONFIG"
So prior to references to the possibly-mapped global, you'd look to see if there's an override for the current namespace, and if there is, use it.

Timothy Leavitt · Jun 28, 2024 go to post

Sorry we missed that. I started to look around for best practices and forgot to circle back.

It's a fantastic question, and I think your gut feeling from https://github.com/intersystems/git-source-control/discussions/343 is correct - the local-to-the-server repo should be in a place accessible from all mirror members, provided you can do this in a way that doesn't introduce a single point of failure operationally.

If that location is unavailable, you won't be able to do development, but operations on the running instance shouldn't be impacted otherwise (and that location being unavailable would be something that needs to be fixed immediately anyway).

Timothy Leavitt · Jul 9, 2024 go to post

Hi @Kwabena.Ayim-Aboagye - zpm "generate" will create module.xml in a folder on the IRIS server, and if you specify the folder that holds your code it should discover the things that are already in that folder and add them to module.xml.

Timothy Leavitt · Jul 12, 2024 go to post

I strongly relate to this. Zen was a huge part of what sold me on InterSystems tech 15 years ago when I started here as an intern - for all the reasons you've described - and if I want to throw together a really quick POC that just has results of a class query shown in a table, with maybe some basic interactions with the data, I might still use it.
That said, for my team's work and even for my own personal projects, I've found the combination of isc.rest and isc.ipm.js to be *almost* as quick as Zen. With something like Angular with an IRIS back-end (consisting of a bunch of %Persistent classes), you need to write:
1. REST APIs for all your basic CRUD operations, queries, and business logic
2. Client code to call all those REST APIs
3. Client code for all the models used in those REST APIs
4. The actual UI
Suppose you want to make a simple change to one of your models - say, adding a property to a class and making it available in the UI. With Angular, this probably means changes at all four levels; with Zen, you get to skip 1-3 entirely. That's compelling. An inevitable side effect of this is that your application's API surface (and therefore attack surface) is enormous and near-impossible to fully enumerate. It is possible to secure a Zen UI, but much easier to shoot yourself in the foot.
isc.rest makes (1) super easy - add a parent class to your %Persistent class and do a few easy parameter/method overrides to get CRUD and queries basically for free, and write a bit of XML if you want to do fancier things to expose business logic or class queries. This provides enough metadata to generate an OpenAPI spec, which can then be used to automate (2) and (3) with the help of openapi-generator. So while you can't skip 1-3 entirely, this toolset makes it all significantly faster.

Timothy Leavitt · Aug 13, 2024 go to post

This is old enough to post a spoiler now - I got down to 35 with the *i trick; what's the 34-character solution?
 

 

Spoiler

 
Classascii.ascii
{

ClassMethodascii()
{
 f i=32:1:126{w:$t(+6)'[$c(i) *i}
}

}

 

Timothy Leavitt · Aug 27, 2024 go to post

Hi @Jani Hurskainen - the short answer is "yes, TestCoverage is coupled to %UnitTest."
Can you elaborate on what you have in mind by "other unit testing frameworks" and/or what you're trying to achieve? %UnitTest is the only unit testing framework for ObjectScript that I'm aware of.
 Is your objective to unify Python and ObjectScript unit tests?

Timothy Leavitt · Aug 27, 2024 go to post

Ahh, I see. Honestly, if you're looking to adjust the two things to work together, you might be better off writing an adapter layer between %UnitTest.TestCase and your existing test case parent class rather than trying to make TestCoverage work for your custom unit test framework.

Timothy Leavitt · Sep 30, 2024 go to post

isc.ipm.js supports Angular and React currently; we'd welcome a PR or issue for Next.js. Probably not too much work needed to support it, it's just a matter of determining the build and static files layout.

Timothy Leavitt · Oct 1, 2024 go to post

The purpose of IRIS embedded source control features is to keep code changes made in the database synchronized with the server filesystem, to automate any source control provider-specific operations in a way that ensures that synchronization, and to provide concurrency controls for developers working in a shared environment (when relevant). In the days of Studio, all code changes were made in the database first, rather than on any filesystem, so you needed an embedded source control solution to get real source control at all. With client-side editing in VSCode, there are *still* some changes to code that are made "in the database first" - specifically, all the management portal-based graphical editors for interoperability and business intelligence. For such use cases, embedded source control is relevant even when you're developing against a local Docker container (which I'd consider modern best practice and prefer over a remote/shared environment where feasible) - otherwise, you need to jump through extra hoops to get your changes onto the client/server filesystem.

In a client-centric mode, it's totally fine to use git-source-control alongside the git command line, built-in VSCode tools, or your preferred Git GUI (GitHub Desktop, GitKraken, etc). However, this misses an important benefit of git-source-control: when you pull, checkout, etc., if you do it through the extension, we can automatically reflect the operation in IRIS by loading added/modified items and deleting items that have been removed in the database. If you make changes on the filesystem through one of these other channels, it's up to you to make sure things are reflected properly in IRIS.

Another benefit of git-source-control for local development is that when working across multiple IPM packages loaded from separate local repos, changes made via isfs folders will automatically be reflected in the correct repository. This is more natural for established ObjectScript developers especially (e.g.: "I just want to edit this class, then this other class in a different package") than a client-centric multi-root VSCode workspace, which could achieve the same thing but with a bit more overhead.

Timothy Leavitt · Oct 28, 2024 go to post

Perhaps the private webserver is running on 52773 inside the container and exposed as 52774 on the host? So from within the container you should connect to localhost:52773 instead of 52774.

Timothy Leavitt · Oct 30, 2024 go to post

Confirmed - OCI/ORAS will be supported in the next major release after v0.9 and getting this wrapped up is our top priority.

Timothy Leavitt · Oct 31, 2024 go to post

Great question! I mean the client (install -v moduleName / etc.) - will clarify in the original question.

Timothy Leavitt · Nov 4, 2024 go to post

@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.

Timothy Leavitt · Nov 4, 2024 go to post

@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-in… 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!