FWD » Testing

See #9202-32 for a version of the date.java tests written to run in ABLUnit. The only "problem" is that each test is grouped as a set of related tests rather than being its own @Test method.

We probably should also rename TestCase.cls to something more obviously specific to date testing.

There are also a number of 4GL test classes I wrote for DATE type and date FILL-IN-related issues. Some are linked to related tasks, while others have not yet been published. I will publish them after May 12, 2025.

Additionally, there are several standard non-4GL JUnit5 test classes within the FWD framework, located in the test/ source directory under the com.goldencode.p2j.util package. IMO these should be reviewed, rewritten in 4GL as ABLUnit tests (integrating their logic into existing ABLUnit tests where possible), and eventually eliminated to reduce possible code duplication across Java and 4GL, thereby simplifying project maintenance.

Greg Shah wrote:

In addition to moving these tests into ABLUnit, please create lexer tests for each of the literal values AND ensure the cases from #9963 are included as ABLUnit tests.

I added tests/primitive_type/date/DateDefinitionsTests.cls which contains ABLUnit tests for the cases from #9963.

I have also added lexer tests for the literals from ##9963 and #9202-32, they are in tests/conversion/lexer/4gl_testcases/dates, there are also corresponding test plans for them.

Last Testcases rev is 1750.

There are many date literals in the date.java tests which are not present in the lexer testcases. To be clear: all dates present in mdyTests and ymdTests should be included in the lexer literal tests.

Greg Shah wrote:

There are many date literals in the date.java tests which are not present in the lexer testcases. To be clear: all dates present in mdyTests and ymdTests should be included in the lexer literal tests.

I've fixed that and made a commit to testcases. I included all literals in a test and then duplicated the tests to cover the quoted version too. I've also added the harness tests for FWD and OE.

I’ve attached the following ABLUnit classes for testing date format validation and parsing:

Do any of these relate to the purpose of this task? These sound useful but it is not clear to me how they relate. Florin has implemented tests to replace the testing in date.main().

Any additional tests should be checked in to the testcases project.

Greg Shah wrote:

I’ve attached the following ABLUnit classes for testing date format validation and parsing:

Do any of these relate to the purpose of this task? These sound useful but it is not clear to me how they relate. Florin has implemented tests to replace the testing in date.main().

My tests are a superset of the tests in date.main(). I believe they should either be merged or, at the very least, positioned near each other in the repo.

Any additional tests should be checked in to the testcases project.

Agreed. To support this an instruction should exists on where to put such sources, the rules on how the classes and directories should be named, how the documentation for the test should look like, and where the documentation should be placed. Otherwise nobody will find them :-(

Ran into another problem: I can’t access the testcases repo myself due to a connection issue: the attempt fails after a 300-second timeout is exceeded.

To support this an instruction should exists on where to put such sources, the rules on how the classes and directories should be named, how the documentation for the test should look like, and where the documentation should be placed. Otherwise nobody will find them :-(

Base Language Testcases
Database/Persistence Testcases
User Interface Testcases
Runtime Infrastructure Testcases

These are being edited by Marian right now as they are working to get the documentation updated to match the current tests.

Your tests might cross over the boundaries of the Format String Tests and Format String (UI) Tests.

Greg Shah wrote:

Florin: Do the tests all pass in both OE and FWD?

• In OE all tests PASS.

• In FWD:
  • For tests/primitive_datatypes/YmdDateTest.cls we have two failing tests:
    

    @Test.
     method public void test70().   
         Assert:isTrue(new TestCase(date(1, 1, 5),    "?????",       "9-9-9", 1, 1, 5, 5):test()).   
     end method.
    
    @Test.
     method public void test71().   
         Assert:isTrue(new TestCase(date(1, 1, 5),    "0005.00001.00001", "99999.9999.99999", 1, 1, 5, 5):test()).   
     end method.
    

  • For tests/primitive_datatypes/MdyDateTest.cls also two failing tests:
    

       @Test.
        method public void test70().   
            Assert:isTrue( new TestCase(date(1, 1, 5),    "?????",       "9-9-9", 1, 1, 5, 5):test()).   
        end method.
    
       @Test.
        method public void test71().   
            Assert:isTrue( new TestCase(date(1, 1, 5),    "00001.00001.0005", "99999.9999.99999", 1, 1, 5, 5):test()).   
        end method.
    

    
    These failures were also mentioned in date.java comments.
  • For the additional tests we have in tests/primitive_datatypes/DateDefinitionsTests.cls, the compilation fails because of the line
    DEFINE VARIABLE d1 AS DATE NO-UNDO INITIAL 01022999. , even though it is OE-valid.

Vladimir Tsichevski wrote:

Ran into another problem: I can’t access the testcases repo myself due to a connection issue: the attempt fails after a 300-second timeout is exceeded.

Vladimir, if you're using checkout with ftp, try the ssh. That worked for me when I had the same issue.

Florin Eugen Rotaru wrote:

Vladimir Tsichevski wrote:

Ran into another problem: I can’t access the testcases repo myself due to a connection issue: the attempt fails after a 300-second timeout is exceeded.

Vladimir, if you're using checkout with ftp, try the ssh. That worked for me when I had the same issue.

I use bzr+ssh://vvt@xfer.goldencode.com/opt/testcases/. Today the weather is good and ssh is working :-)

As a fallback, you can try creating a tunnel to 192.168.1.37 on our internal GCD network. That is the same system as xfer.goldencode.com. I think some people have found that it is faster to access that system via tunnel.