PSUNIT – a few odds and ends

This is a quick follow-up to the earlier posts I’ve made about PSUnit.  To get more familiarity with the tool I had started to build tests against a piece of a project I had just finished up and moved into production.

I was confident the code in the project was good as I had run test files against it continuously as I was coding.

A PSUnit test found a bug.

Ouch.  Glad I found it and not someone else, and it’s good to have found it now while other parts of the project are still outstanding.  And I’m kicking myself for not having used the PSUnit tool while I was writing the code for the project.

One more thing.  I’ve zipped up a project based on the code provided in the readme file you get if you install the PSUnit tool.  It’s available here.  I created it going thru the readme step by step – the code in the zip file is the result.  It was built using PTools 8.51.

PSUnit – Adding Tests

In my previous post I showed the various Assert tests that come with the PSUnit project.  I decided to add another test to the code.

There is only a single boolean Assert test – which checks if the value is True.  But there are times when a boolean False is the correct response.  So I added an AssertFalse test to the code:

AssertFalse(&isTrue As boolean, &onFail As string);

If the value in &isTrue is True, then the test fails.

Clearly you need to have pulled the PSUnit project into a PeopleSoft database instance and created the tables.  From here, start App Designer and open the TTS_UNITTEST Application Package.

You want to click on the TestBase app class and view the PeopleCode associated with it.

In the class TestBase I added the method definition:

  • method AssertFalse(&isTrue As boolean, &onFail As string);

Then I added the code for the method:

/* This was added to test for boolean False values */
method AssertFalse
   /+ &isTrue as Boolean, +/
   /+ &onFail as String +/
   If (&isTrue) Then
      throw create TTS_UNITTEST:Exceptions:AssertFailed(&onFail);

How is this useful?  Let’s take an example of checking for a valid emplid.  I have a method:

method isEmplidValid
   /+ &empID as String +/
   /+ Returns Boolean +/
   Local boolean &_rtn = False;
   Local string &_msg;
   Local SQL &_sql;
   &_sql = GetSQL(SQL.VALID_EMPLID_CHECK, &empID);
   While &_sql.Fetch(&_msg)
      If &_msg = “X” Then
         &_rtn = True;
   Return &_rtn;

The SQL definition is fairly simple:

   AND A.EFFDT = (

This method validates emplids against the JOB table.  A return of False is a correct data state in this instance.  The Assert test would throw an error even though I should expect some values to return as false.

Next I create the tests.  I have two arrays – one has valid emplids for the organization; the other has invalid emplids.  I can now do both positive and negative testing with this method:

method TestIsEmplidValid
   %This.Msg(“TestFieldsCheckField: TestCheckChars”);
   Local boolean &rtn;
   Local integer &i;
   &rtn = False;
   Local PKGE:EMPLOYEE:CheckEmplid &target = create PKGE:EMPLOYEE:CheckEmplid();
   /* First the positive test */
   For &i = 1 To &_EmplidArray.Len;
      %This.Msg(“TestIsEmplidValid: Assert Test Value: ” | &_EmplidArray [&i]);
      &rtn = &target.isEmplidValid(&_EmplidArray [&i]);
      %This.Assert(&rtn, “Assert method failed”);
   /* Then the negative test */
   For &i = 1 To &_BadEmplidArray.Len;
      %This.Msg(“TestIsEmplidValid: AssertFalse Test Value: ” | &_BadEmplidArray [&i]);
      &rtn = &target.isEmplidValid(&_BadEmplidArray [&i]);
      %This.AssertFalse(&rtn, “AssertFalse method failed”);

Having the AssertFalse method allows me to confirm that my checking routine is working correctly.  I’m able to test that my program can gracefully handle invalid/incorrect data.

PSUnit Assert Tests

PSUnit provides a series of Assert tests.  In the article provided as part of the zipped download Jim Marion goes step by step into the process of creating a test.  However he only uses a single test: AssertStringsEqual.

I dug into the code and listed the tests you can do with PSUnit.

Assert(&isTrue As boolean, &onFail As string);

If the value in &isTrue is False, then the test fails.  From the program notes:

The first argument must be a boolean expression, which should evaluate to true.  If false, PSUnit throws an exception to indicate that the test failed.  The test runner catches the exception, marks the test as having failed, and continues on to the next test.

AssertStringsEqual(&str1 As string, &str2 As string, &onFail As string);

AssertStringsDiffer(&str1 As string, &str2 As string, &onFail As string);

AssertNumbersEqual(&num1 As number, &num2 As number, &onFail As string);

AssertNumbersDiffer(&num1 As number, &num2 As number, &onFail As string);

AssertDatesEqual(&date1 As date, &date2 As date, &onFail As string);

AssertDatesDiffer(&date1 As date, &date2 As date, &onFail As string);

AssertRowsetValuesEqual(&rs1 As Rowset, &rs2 As Rowset, &onFail As string);

Method first checks the ActiveRowCounts between the two rowsets.

Then the method tests that both rowsets come from the same Record.

Finally the method tests the fields in each row of each rowset for equality.

If an Assert test fails, the exception text which includes whatever message you pass on as part of the variable  &onFail gets sent to Class AssertFailed; which then calls the PeopleCode function CreateException.

PeopleSoft PSUnit

I first came across PSUnit in Jim Marion’s book PeopleSoft PeopleTools Tips & Techniques.  It’s a different tool from Test Framework – and you should consider it as complementary to PTF.

Jim has a write up of it here; there is another small explanation of it here.  Both articles give a link to the code, or you can get it here.

PSUnit is a Test Driven Development tool.  With Test Framework you code, create a page, and then put your page into a component.  The component gets applied to a menu which then get set into the registry.

With PSUnit you create a test framework Application Package, which gets plugged into an already existing test page.  Better yet – while Test Framework can help to point out where a transaction throws an exception, PSUnit lets you dig further and find out why.

From Jim Marion’s blog piece PSUnit Unit Testing Framework:

You, the developer, receive a notification from a user that page X of component COMP_X is calculating the wrong values. The user informs you that the calculation and error occur when he/she clicks save. From this information, you speculate that the calculation happens in the SavePreChange or SavePostChange event of the component or some record used in the component. Unfortunately, you are not familiar with this page or component.

With a PeopleCode trace, you are able to identify six potential events. You notice that these events call FUNCLIB’s and App Classes creating a horrendously deep call stack. From what you have in front of you, it is obvious that a quick review of this 3,000+ line trace file won’t provide an easy solution.

At this point you have several options:

Continue to treat COMP_X as a black box, investigating it from the outside.

Dig into the code and speculate as to its purpose.

Configure app server debugging and step through the deep call stack.

Start adding MessageBox statements to the delivered code so you can interrogate the state of the application as it runs.

We will choose the final option, the MessageBox option. Yes, this will require us to modify delivered code, but this modification should have no impact on the behavior of the code. The modification doesn’t concern me as much as forgetting to delete one of those MessageBox statements after I find and fix the problem. And then, once I find the correct combination of MessageBox statements to show the problematic data or logic, I hate to delete them, knowing I may have to visit this code at a future date (sooner then I want, but far enough in the future that I’ve already forgotten how I solved the problem). Wouldn’t it be nice if, once you found the appropriate combination of logging statements, you could just leave them in the code?

You should read the entire post.  I’ll list the various Assert tests that are available in another post.


I keep telling people who come to me for help that it’s always the simple things. That little gotcha you forgot, glossed over, didn’t think about…

A simple thing. An easy peasy every day thing. Disable a column in a PeopleSoft page.

The code resides in an Application Package:

method MyMethod
  /+ &grid_name as String +/ Local array of array of string &enable;   


  Local Grid &mygrid = GetGrid(@&my_page, &_grid);


The above method gets called by a test method in another App Package – I’m using a tool called PSunit for my unit testing:

method Test_MyMethod
   %This.Msg(" ");
   %This.Msg("Test_GridUtils: Test_MyMethod: " | &WRK_TBL);

I attached a test page to the PSUnit component. I figured I’d be able to see the results after I fired the test.The test ran fine. No errors. But… the grid on the test page never changed.

I spent a couple of hours between meetings trying to get the grid on the test page to work. Everything worked fine. Just… no change to the grid. Worse the grid showed the data I sent to it as part of the test, it was the disabling of columns and the hiding of columns that didn’t take place.

After checking and rechecking syntax, spelling, specifications of the methods I was using I finally re-read the specification of the Grid Class in PeopleCode and found this line:

The attributes you set for displaying a page grid remain in effect only while the page is active.


Placed the call to the method in the page activate event for the page.


A simple thing.


Application Package Weirdness

I’m in an environment that is at PTools level 8.53.  I’ve got a App Package with three classes, and I’m using PSUnit to test the various class methods before I use them in as part of a project I’m working on.

I’ve got a method that simply finds the next Saturday from the current date.  It’s very simple:

* Sets the amend effective date to the
* next Saturday following the current system date.
method SetNextSaturday
Local string &sql = “SELECT NEXT_DAY(sysdate,’SATURDAY’) from dual”;

SQLExec(&sql, &amend_effdt);


The output bind variable &amend_effdt is defined as a private instance for the class.  The method SetNextSaturday is invoked within the class constructor, meaning that as soon as the class object is instantiated the method gets called.

My test is also very simple:

method Run_DateUtils
Local ZG_NEG_AMEND:AmendNegotiation:DateUtils &util = create ZG_NEG_AMEND:AmendNegotiation:DateUtils();
Local date &amend_dt = &util.amendEffDt;
Local string &sql = “SELECT NEXT_DAY(sysdate,’SATURDAY’) from dual”;
Local date &next_sat;
SQLExec(&sql, &next_sat);
%This.AssertDatesEqual(&amend_dt, &next_sat, “Method DateUtils not deriving amend date correctly!”)

When tested this error is thrown:

Test [ZG_NEG_AMEND_TEST:TestDateUtils] failed!
SqlExec: parameter 2 is neither a record object nor a name. (2,284)

Odd.  The SQL runs perfectly in SQL Navigator.

And then I looked at the error explanation.  Parameter 2 is a problem.  Hmmmm.

So I refactored by declaring a local date variable in the method, then assign it’s value to the instance variable.  That worked.  That’s also ugly.

This has also been a problem since 2008 PTools version 8.44 based on this post.  It seems that a property cannot be an output argument of a function, and that an instance variable is treated as a property.

What makes this more confusing is apparently an instance variable is fine for input.  It can be read from, just not written to.

%d bloggers like this: