FWD » Core Development » Base Language

While investigating another issue, I found this testcase which has the wrong behaviour in FWD:

block-level on error undo, throw.

def temp-table tt1
field f1 as int
field f2 as int
index idx1 as unique f1 .

def temp-table tt2
field f1 as int
.

create tt1.
tt1.f1 = 1.

create tt2.
tt2.f1 = 1.

create tt1.

procedure p1:
    for each tt2 on error undo, throw: 

    assign
        tt1.f1 = 1
        tt1.f2 = 2.       
     end.

message 'end procedure'.
end.

do on error undo, throw:
    run p1.
    message 'after test'. // FWD
    catch err as Progress.Lang.Error:
        message 'in catch block'. // OE
    end.

end.

The original discussion is #9753, starting in #9753-38.

The solution is already in 9753a/15849. Constantin, please review it when you are available.

Andrei Plugaru wrote:

Constantin, can we move on to testing? If yes, I can do the unit tests and fwd tests of a large customer application. Do you think anything else is necessary?

Yes, go ahead. Please also update the %Done.

1. fwd tests and unit tests [me]
2. unit tests of large customer application [ai]
3. unit tests of large customer application [ls]
4. unit tests of large GUI application [sb]
5. smoke tests of large GUI application [ab2] ✅

Important: the task branch is 9753a.

I found a smaller recreate of the failing test:

using OEUnit.Assertion.Assert.

routine-level on error undo, throw.

class DuplicationTest:

   method private void setup1(): 

      create t1.
      assign
         t1.f1           = "a" 
         t1.f2 = "b" 
         .
      release t1.

   end method.

      @Before.
   method public void PreTestSetup():
       for each t1:
           delete t1.
           end.
      setup1().
      setup2().

   end method.

   @Test.
   method public void test(): 
      Assert:IsTrue(true).

   end method.

   method private void setup2 (): 

      create t1.
      assign
         t1.f1           = "a" 
                  t1.f2 = "b" 

         .
      release t1.

   end method.

end class.

When running this in OE, the behaviour is quite strange. This isn't classified as either a failure or success.
By default, in FWD, the same behaviour is preserved. Even though, the test has a failure message, it is not classified either as a failure or success. This is the exact output:

Failures (1):
  FWD Test:TestSuite:DuplicationTest
    ClassSource [className = 'com.goldencode.dataset.DuplicationTest', filePosition = null]
    => org.opentest4j.AssertionFailedError: ** t1 already exists with f1 "a". (132)
       com.goldencode.p2j.oo.lang.SysError.newInstance(SysError.java:151)
       com.goldencode.dataset.DuplicationTest.setup2(DuplicationTest.java:103)
       com.goldencode.dataset.DuplicationTest.setup2(DuplicationTest.java:100)
       com.goldencode.dataset.DuplicationTest.preTestSetup(DuplicationTest.java:83)
       com.goldencode.dataset.DuplicationTest.preTestSetup(DuplicationTest.java:68)

Test run finished after 181 ms
[         3 containers found      ]
[         0 containers skipped    ]
[         3 containers started    ]
[         0 containers aborted    ]
[         2 containers successful ]
[         1 containers failed     ]
[         1 tests found           ]
[         0 tests skipped         ]
[         0 tests started         ]
[         0 tests aborted         ]
[         0 tests successful      ]
[         0 tests failed          ]

However, comparing the old logs of the unit tests of the large customer application, the error message was not present at all. So, I was trying to understand the difference. During debugging, I understood that at some point in the large customer application, a PersistenceException is raised because an unique index was violated. This didn't happen in my small testcase. So, I tried to understand the difference between my env and the one from the large customer application. One curcial difference is that when my database is imported, the indices are not created at the DB level. I am not sure why schema_index_fwd_*.sql isn't run by default. However, the SQL scripts that are run in the client's env, also create the indices.

So, I have manually run the SQL command to create the index, and I got the same behavior as in the large customer application. With trunk, the test was successful(with no error message), but with 9753a, I wasn't getting either a failure nor success.

IMHO, I don't see why such a test would be successful, so the changes in 9753a actually get us closer to the OE behaviour. The next step would be to check this test with a newer OE version and take a decision based on that.