#Testing

One of the pain points for maintaining HL7 interfaces is the need to run a reliable regression test upon deployment to new environments and after upgrades. The %UnitTest class allows unit tests to be created and packaged alongside interface code. Test data can also be maintained within the unit test class, allowing for quick and easily repeatable smoke-testing and regression testing.

Resources:

• Standard %UnitTest class

In this series of articles, I'd like to present and discuss several possible approaches toward software development with InterSystems technologies and GitLab. I will cover such topics as:

Astronomers’ tools

5 years ago, on December 19, 2013, the ESA launched an orbital telescope called Gaia. Learn more about the Gaia mission on the official website of the European Space Agency or in the article by Vitaly Egorov (Billion pixels for a billion stars).

However, few people know what technology the agency chose for storing and processing the data collected by Gaia. Two years before the launch, in 2011, the developers were considering a number of candidates (see “Astrostatistics and Data Mining” by Luis Manuel Sarro, Laurent Eyer, William O’Mullane, Joris De Ridder, pp. 111-112):

• IBM DB2,
• PostgreSQL,
• Apache Hadoop,
• Apache Cassandra and
• InterSystems Caché (to be more precise, the Caché eXTreme Event Persistence technology).

Comparing the technologies side-by-side produced the following results (source):

The first four will probably sound familiar even to schoolchildren. But what is Caché XEP?

If you have already built unit tests using the %UnitTest framework, or are thinking about doing so, please take a look at InterSystems Testing Manager.

Without leaving VS Code you can now browse your unit tests, run or debug them, and view previous run results.

I found the need to merge 2 Docker images
(e.g. intersystems/iris-community:2020.2.0.199.0 + my home grown NodeJS Image).
I found some advice on the Web but no real convincing solution.

We've recently made available a new version of InterSystems IRIS in the Vector Search Early Access Program, featuring a new Approximate Nearest Neighbor index based upon the Hierarchical Navigable Small World (HNSW) indexing algorithm.

Hey everyone,

Here we are again. New year, new contest, new project, old reasons.

Triple Slash is in the house!

There are many applications for working with HL7 V2 messages, but the tools for working with XML in IRIS Management Portal and Cache Studio are limited.

In the default IRISterminal or using PuTTY I have a set of "Routine Commands" available

Hi Community,

In this article, I will introduce my application iris-HL7v2Gen .

IRIS-HL7v2Gen is a CSP application that facilitates the dynamic generation of HL7 test messages. This process is essential for testing, debugging, and integrating healthcare data systems. The application allows users to generate a wide variety of HL7 message types, validate their structure against HL7 specifications, explore the message hierarchy, and transmit messages over TCP/IP to production systems. These features are particularly useful in settings where compliance with HL7 standards is mandatory for interoperability between different healthcare organizations or systems.

Application Features

• Dynamic HL7 Message Generation: Instantly create HL7 messages for a range of message types, facilitating comprehensive testing.
• Message Structure Exploration: Visualize the structure of generated messages based on HL7 specifications.
• Value Set Visualization View predefined sets of allowable coded values for specific fields.
• Message Validation: Validate messages against HL7 standards to ensure compliance.
• TCP/IP Communication: Easily transmit messages to production using TCP/IP settings.
• Broad Message Type Support: Supports 184 different HL7 message types, ensuring versatility for various healthcare integration needs.
• ClassMethod: Generate a Test Message by Invoking a Class Method
• Version Support: Currently Supports HL7 Version 2.5

Hi Developers!

Recently we discussed the naming convention on packages we deploy and even made some choices.

Here I want to have a conversation on the naming convention for unit tests.

Of course, we wish every good library has unit tests. Here is the documentation and some good articles(one, two, three) regarding it on the Developer Community.

Let's decide on the naming of UnitTests packages?

The suggestion is that unit test classes will all start with the UnitTest package name.

E.g. if your library's class name is:

johndoe.lib.class

The related unit test class will be:

UnitTest.johndoe.lib.class

What about folders?

The suggestion is that unit test classes will live separately from source classes, e.g. in /tests directory.

Here is the example of a repository with unit tests that are named and placed according to the proposal.

What do you think?

A few years ago, I was teaching the basics of our %UnitTest framework during Caché Foundations class (now called Developing Using InterSystems Objects and SQL). A student asked if it was possible to collect performance statistics while running unit tests. A few weeks later, I added some additional code to the %UnitTest examples to answer this question. I’m finally sharing it on the Community.

Hi everyone,

In this article, I’m excited to introduce CodeInspector, a tool designed to simplify code validation by applying custom rules tailored to your development requirements. Whether you're managing a large codebase or working in an agile environment, CodeInspector helps ensure code quality by offering flexibility and adaptability to specific project needs.

At hackathons that InterSystems participated and I supported, many students were asking how all their teammates could use the same IRIS database that they spun up in a container. I suggested using ngrok to expose their localhost IRIS and realized we don't have documentation on that. Hence, I thought this would be great to let more people knwo about this powerful technique for enhancing collaboration during development and testing.