#Testing

During my search for a snapshot of a persistent object,
I met a feature that I would like to share as it could be useful in some special situations.
My trigger was to have a before- and an after-image during unit testing.

It is with great pleasure that the CIUSSS de l'Estrie - CHUS is sharing the mocking framework it developed and presented at the InterSystems Summit 2017. I will update this post with more detailed instructions in the next few weeks but I wanted to share the code and presentation quickly :

https://gitlab.com/ciussse-drit-srd-public/Mocking-Framework

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:

The Command extension enables the execution of Multi-Line Commands from Terminal prompt.

Installation & Execution

Import %ZML.xml to Namespace %SYS

Optionally you may add this line to your %ZLANGC00.mac for a simplified use:

ZML do ^%zml quit  ; add multi line command in terminal

and
USER>zml

otherwise, just call it from the terminal command prompt

The Command extension enables the execution of Multi-Line Commands from Terminal prompt.

Terminal Multi-Line Input with Edit, Insert, Delete, Print extension for IRIS and Caché
IRIS and Caché have just single command lines in terminal available
This Multi-Line Commands Editor also will execute the Multi-line Commands.
In addition, it is independent of access to %SYS and can be installed in any namespace

Special thanks to @Jeffrey Drumm who inspired me to this and supported me as beta-tester.

Hi Developers!

Often solutions with InterSystems IRIS BI can turn into a quite big solution with dozens of pivots and dashboards.

With every new IRIS BI solution release we can add changes that could influence the behavior of existing pivots or dashboards so they stop working. For example if we change the dimension or measure name, forget deploying some cubes or subject areas, conduct refactoring via mass renaming of cubes and its elements etc some widgets could stop functioning.

Hey everyone,

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

Triple Slash is in the house!

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 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?

Hi Developers!

I want to share with you the approach you can use working with Unit Testing which I personally find very convenient and robust.

Will not talk much here about Unit Testing, we have documentation, enough good articles on the topic not only on the Internet but here on Developers Community too, e.g. this one.

How can you manage the Unit Testing of your ZPM module?

This is pretty handy with ZPM. It has a special command "test" which runs all the tests you mentioned in the module. You can execute it as shown below:

zpm:USER>module-name test

And this command runs all the tests you mentioned in module.xml.

Let's see how it works.

Continuing on the journey of implementing %UnitTest, @Timothy Leavitt's Test Coverage package, and automated testing with Jenkins.

My question today: why do we utilize a unit test root directory?

IRIS Interoperability Productions formerly known as Ensemble are fun to work with. Yes, I really think my work is fun. I have seen File Passthrough Services and File Passthrough Operations come in handy. At one point we placed test messages in files, then we utilized a File Passthrough Service with Inbound File Adapter to send the contents of the file as a Stream to a File Passthrough Operation with Outbound TCP Adapter.

Often InterSystems technology architect team is asked about recommended storage arrays or storage technologies. To provide this information to a wider audience as reference, a new series is started to provide some of the results we have encountered with various storage technologies. As a general recommendation, all-flash storage is highly recommended with all InterSystems products to provide the lowest latency and predictable IOPS capabilities.

The first in the series was the most recently tested Netapp AFF A300 storage array. This is middle-tier type storage array with several higher models above it. This specific A300 model is capable of supporting a minimal configuration of only a few drives to hundreds of drives per HA pair, and also capable of being clustered with multiple controller pairs for tens of PB's of disk capacity and hundreds of thousands of IOPS or higher.

Hey community!

It's time to elevate your unit tests to the next level with iris-TripleSlash new solo feature!

We are bring to the game Setup and Tear down events!

Just add description on class, with special tags like:

• beforeAll
• beforeOne
• afterAll
• afterOne

The tripleSlash will turn it to: