OUnit Test suite in 21.4 CSIDE

HFCDev · 2021-11-19T22:32:08+00:00

There was an error rendering this rich post.

Hi,

When I upgraded CSIDE, I noticed a new control, an OUnit test control:

It looks like an Oscript version of the JUnit test suite you find in your typical Java project. As someone who is trying to implement more TDD in my Oscript development, I have to ask if there is any guidance on how to use OUnit tests? I haven't found any documentation on it, but I'd love to align my development practices closer to what OpenText DEV is doing.

Looking forward to hear more about this.

-Hugh

Find more posts tagged with

Comments

Dave Carpeneto

Hi Hugh - documentation was supposed to be included alongside this. Apologies for the disconnect over here - I'll check to see where things are.

As an aside - the view above is there to help with the running & analysis of unit tests - the actual functionality is contained in the UNITTEST OSpace (which we've been shipping for a while now). The docs should cover what needs done at a high level, but till then if you want to snoop around / play with things the simplest option would be to expand an object in your workspace / OS file, right-click a function that returns something, and select "generate unit tests". This'll create a test OSpace in your project. Set fEnabled to 'true', override TestSubclassAssert() to check the results from your function, build the test OLL & then right-click the test OLL & select 'run tests'. You should see some XML dumped to the console. Just something for you to play with whilst we get our act together WRT the docs :-)

HFCDev

Interesting. It creates a whole new ospace both in Eclipse src but also in your module directory. But it doesn't add it to the module.ini file. Given I haven't seen OT ever ship a module that had a _Test.oll I'm assuming that they are removed either manually or by whatever build process is used internally. It looks like you create one object per function as opposed to one object per class you're testing which could make for a crowded view. I'm a little unclear why it generates for a function named MyFunction, 3 classes - one called TestMyFunction, then one of each of success and failure. I'm a little unclear where I should be putting my code to test the function.

I'd be curious to know how widely this is used inside OpenText. I notice that it looks a lot like a JUnit test framework and probably your dev teams have been or moving towards a TDD approach.

-Hugh

Dave Carpeneto

But it doesn't add it to the module.ini file.

That's correct - test OLLs are only loaded if you're running via CSIDE. In "normal" server operation the test OLLs are ignored.

I'm assuming that they are removed either manually or by whatever build process is used internally.

Also correct :-)

I'd be curious to know how widely this is used inside OpenText

It's been used internally for many years. Some modules have several hundred individual tests. There is (obviously) a large push for us to add tests wherever possible.

3 classes - one called TestMyFunction, then one of each of success and failure

This is what we generate as a skeleton. Typically you put code to test a successful result in the success object & the failure object houses tests that should fail. If you have multiple success cases to test then over here we tent to have multiple objects under the success object. But what you put where is up to you.

it looks a lot like a JUnit test framework

It's similar in that both frameworks are based off https://en.wikipedia.org/wiki/XUnit .

Greg Griffiths

see https://knowledge.opentext.com/knowledge/llisapi.dll/fetch/-15106263/15106294/15106295/16376487/78335947/78339425/78337965/78349453/-/ounit.html

Dave Carpeneto

Ha - thanks for this. I was waiting for the KC team to let me know when this went up 🙂

FWIW https://knowledge.opentext.com/knowledge/llisapi.dll/fetch/-15106263/15106294/15106295/16376487/78335947/78339425/78337965/-/cside/ounit.html is a slightly more readable version, since there are some code snippets to help you write your own test logic.

Greg Griffiths

@Dave Carpeneto would be good to get this into the training docs as its still missing :(

Dave Carpeneto

You're correct. There's a fair bit that could be added. I'll flag this to the training department :-)