Comments (2)

By spgennard, November 6, 2009 8:44 pm

A while back, I spent a afternoon converting some C# NUnit documentation into COBOL .Net, so I thought I would share the document with the world, with the hope that it will help any one interested in using NUnit and COBOL.

Enjoy!

Let’s start with a simple example. Suppose we are writing a bank application and we have a basic domain class – Account. Account supports operations to deposit, withdraw, and transfer funds. The Account class may look like this:

Now let’s write a test for this class – AccountTest. The first method we will test is TransferFunds.

The first thing to notice about this class is that it has a TestFixture attribute associated with it – this is the way to indicate that the class contains test code (this attribute can be inherited). The class has to be public and there are no restrictions on its superclass. The class also has to have a default constructor.

The only method in the class – TransferFunds, has a Test attribute associated with it – this is an indication that it is a test method. Test methods have to return void and take no parameters. In our test method we do the usual initialization of the required test objects, execute the tested business method and check the state of the business objects. The Assert class defines a collection of methods used to check the post-conditions and in our example we use the AreEqual method to make sure that after the transfer both accounts have the correct balances (there are several overloadings of this method, the version that was used in this example has the following parameters : the first parameter is an expected value and the second parameter is the actual value).

Compile and run this example. Assume that you have compiled your test code into a Example1.dll. Start the NUnit Gui (the installer will have created a shortcut on your desktop and in the “Program Files” folder), after the GUI starts, select the File->Open menu item, navigate to the location of your bank.dll and select it in the “Open” dialog box. When the bank.dll is loaded you will see a test tree structure in the left panel and a collection of status panels on the right. Click the Run button, the status bar and the TransferFunds node in the test tree turn red – our test has failed. The “Errors and Failures” panel displayed the following message – “TransferFunds : expected <250> but was <150>” and the stack trace panel right below it reported where in the test code the failure has occurred “at AccountTest.TransferFunds() in xxxx\Example1\Example1\AccountTest.cbl:line 42”

That is expected behavior; the test has failed because we have not implemented the TransferFunds method yet. Now let’s get it to work. Don’t close the GUI and go back to your IDE and fix the code, make your TransferFunds method look like this:

Now recompile your code and click the run button in GUI again – the status bar and the test tree turn green. (Note how the GUI has reloaded the assembly automatically for you; we will keep the GUI open all the time and continue working with our code in IDE and write more tests).

Let’s add some error checking to our Account code. We are adding the minimum balance requirement for the account to make sure that banks continue to make their money by charging your minimal overdraft protection fee. Let’s add the minimum balance property to our Account class:

We will use an exception to indicate an overdraft:

Add two new classes reference to the repository:

Add a new test method to our AccountTest class:

This test method in addition to Test attribute has an ExpectedException attribute associated with it – this is the way to indicate that the test code is expecting an exception of a certain type; if such an exception is not thrown during the execution – the test will fail.

Compile your code and go back to the GUI. As you compiled your test code, the GUI has grayed out and collapsed the test tree as if the tests were not run yet (GUI watches for the changes made to the test assemblies and updates itself when the structure of the test tree has changed – e.g. new test is added). Click the “Run” button – we have a red status bar again. We got the following Failure : “TransferWithInsufficentFunds : InsufficientFundsException was expected”. Let’s fix our Account code again, modify the TransferFunds method this way:

Compile and run the tests – green bar. Success! But wait, looking at the code we’ve just written we can see that the bank may be loosing money on every unsuccessful funds Transfer operation. Let’s write a test to confirm our suspicions. Add this test method:

We are testing the transactional property of our business method – all operations are successful or none. Compile and run – red bar. OK, we’ve made $300.00 out of a thin air (1999.com déjà vu?) – the source account has the correct balance of 150.00 but the destination account shows : $450.00. How do we fix this? Can we just move the minimum balance check call in front of the updates:

What if the Withdraw() method throws another exception? Should we execute a compensating transaction in the catch block or rely on our transaction manager to restore the state of the objects? We need to answer those questions at some point, but not now; but what do we do with the failing test in the meantime – remove it? A better way is to temporarily ignore it, add the following attribute to your test method

Compile and run – yellow bar. Click on “Tests Not Run” tab and you will see AccountTest.TransferWithInsufficientFundsAtomicity() in the list along with the Reason this test is ignored.

Looking at our test code we can see that some refactoring is in order. All test methods share a common set of test objects. Let’s extract this initialization code into a setup method and reuse it in all of our tests. The refactored version of our test class looks like this:

Note that Init method has the common initialization code, it has void return type, no parameters, and it is marked with SetUp attribute. Compile and run – same yellow bar!

Comments Off

By spgennard, November 5, 2009 2:13 am

This is a very old advertisement of our (Micro Focus) first COBOL debugger called animator in all its glory debugging the classic sample of the day pi.cbl, which calculates the value of PI.

So why is so good?

To put it in some kind of context, most debuggers at the time were command line based, much like gdb, dbx but far less sophisticated.   So having a debugger that actually shows the execution of flow of your, query variables, monitor variables was truly application was amazing.

I have no idea, who put this on YouTube but it really does bring back some old memories.  So thank you!

Comments Off

By spgennard, November 3, 2009 11:16 pm

While working on some support recently for our compiler (Micro Focus COBOL compiler that is), I became annoyed with the lack of a reasonable error messages/stack trace output from our Java/COBOL Object support.

I have no idea why our default exception handler for Java exceptions just displays a such a simple message with little or no information.

For those who have not seen it, display something similar to:

Luckily for me and you, we do expose a mechanism for replacing the default exception handler.

Anyway, with very little effort I created a different “default” system exception handler that display this instead:

The key difference being that a Java stack trace is included, boy did this help me.

The program below is the code that implements the exception handler. I am sure someone else can take this example and make it much nicer and provide more features but for this blog I will keep it simple.

To use the above code, you just have to first cut-paste to code into a file called ExceptionCatcher.cbl and include this in your project, and then add the directive INITCALL”ExceptionCatcher”, then away you go.

My test programs for the above example are:

and the Java class itself:

References: Studio Enterprise 6.0 Document for COBOL/Java Interop