FWD » Core Development » Base Language

Check the tests in Testcases to ensure they are complete and comprehensive. Add tests if needed. Convert and run the tests. Fix any issues as needed until the test pass completely.

These are the features to test:

• GUID/GENERATE-UUID (full/basic)
• HEX-ENCODE()/HEX-DECODE() (full/untested)
• MD5-DIGEST() (full/basic)
• SECURITY-POLICY:REGISTER-DOMAIN() (full/basic)
• SECURITY-POLICY:LOCK-REGISTRATION() (full/basic) used in a FINALLY block

How extensive are the tests? Did you write them or are they pre-existing?

For fixing the compiling issue, I added <action>putNote("classname", "raw")</action> to add classname annotation for MD5-DIGEST. This makes the code from common-progress.rules to add the unknown value on the function call. Is there a more elegant way to fix this issue?

Constantin: Don't we automatically handle this if the parameter is marked as a poly in the signature helper?

There are some tests for MD5-DIGEST (exactly one test method), but I have extended to more methods and added more test cases. I shall commit right now, the tests I have added for MD5-DIGEST?

Yes, please do check them in and update Security Tests with the details of your changes.

+Marian

Commited revision 1753 on testcases.

I have found an issue, but is not related with this task.
For instance, the code provided below fails on FWD:

    @Test.
    method public void testCompleteDecode():
        define variable cLongChar as longchar no-undo.
        define variable rawResult as raw no-undo.
        define variable i as integer no-undo.

        cLongChar = "000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9fa0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebfc0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedfe0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff".
        rawResult = hex-decode(cLongChar).

        do i = 1 to length(rawResult):
            Assert:Equals(i - 1, get-byte(rawResult, i)).
        end.
    end method.

Error:

    [javac] Compiling 10 source files to /home/tg/gcd/testcases2/testcases/build/classes
    [javac] /home/tg/gcd/testcases2/testcases/src/com/goldencode/testcases/tests/base_language/builtin_functions/functionality/TestHexDecode.java:173: error: incompatible types: int64 cannot be converted to integer
    [javac]                return BinaryData.length(rawResult);

Please post what the Java code is on line 173.

We should fix that issue as part of this task.

Constantin Asofiei wrote:

Please post what the Java code is on line 173.

Converted code:

156   @LegacySignature(type = Type.METHOD, name = "testCompleteDecode")
157   @Test(order = 6)
158   public void testCompleteDecode()
159   {
160      longchar cLongChar = TypeFactory.longchar();
161      raw rawResult = TypeFactory.raw();
162      integer i = TypeFactory.integer();
163      
164      internalProcedure(TestHexDecode.class, this, "testCompleteDecode", new Block((Body) () -> 
165      {
166         cLongChar.assign(new character("000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9fa0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebfc0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedfe0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff"));
167         rawResult.assign(SecurityOps.hexDecode(cLongChar));
168         
169         IntegerExpression resExpr0 = new IntegerExpression()
170         {
171            public integer execute()
172            {
173               return BinaryData.length(rawResult);
174            }
175         };
176         ToClause toClause0 = new ToClause(i, 1, resExpr0);
177         
178         doTo("loopLabel0", toClause0, new Block((Body) () -> 
179         {
180            {
181               Assert.legacyEquals(InputParameter.cast(integer.class, minus(new integer(i), new integer(1))), rawResult.getByte(i));
182            }
183         }));
184      }));
185   }

Greg Shah wrote:

+Marian

Yes, tests classes for builtin functions especially only have one test method - the reason is probably because those were generated first to check conversion support. There are usually multiple asserts in that TestFunction method but beside testing the functions with some valid/invalid input parameters asserting the result, afraid there are no tests that can actually help infer the implementation of those functions.

Teodor, what work is left here?

I think there is no more work to do on this task. I am preparing to commit the changes from SECURITY-POLICY. I think I need to revert the fix for UNKNOWN parameter on MD5-DIGEST, since it's an issue which affects on every builtin function which has BDT on signature.

• please rebase
• in BinaryData, why is rely on IndexOutOfBoundsException and not check the bounds via internalLength?

Constantin Asofiei wrote:

Review for 9448a rev 15946:

• please rebase
• in BinaryData, why is rely on IndexOutOfBoundsException and not check the bounds via internalLength?

Rebased branch into rev 16063.
Committed revision 16067 on task branch 9448a:
- addressed code review #9448-21.

• lockRegistration, loadDomainsFailed - isError was changed from false to true - please also check with DO ON ERROR UNDO, LEAVE: ... some code ... MESSAGE "ERROR condition not thrown". END, and not just with NO-ERROR
• loadDomains - why is registry.lock(); called?

Constantin Asofiei wrote:

Teodor, for the changes in SecurityPolicyManager:

• lockRegistration, loadDomainsFailed - isError was changed from false to true - please also check with DO ON ERROR UNDO, LEAVE: ... some code ... MESSAGE "ERROR condition not thrown". END, and not just with NO-ERROR
• loadDomains - why is registry.lock(); called?

On lockRegistration, recordOrShowError is used, with DO ON ERROR UNDO, LEAVE, only records the error (not throw).
On OE 4GL, with DO ON ERROR UNDO, LEAVE block, LOCK-REGISTRATION continues the execution after error. Same happens on FWD.
I changed isError because I get this issue on AssertExt:Error: testMethod ✘ Statement expected to throw error but only raised warning.. This works on OE 4GL, so, it must be an error.

About LOAD-DOMAINS, I have noticed that this method locks the REGISTRY after call. The tests written by Marian checks for this functionality. Please check this example on 4GL OE:

connect db\db1\db1 -1.
// If you place a REGISTER-DOMAIN call here, this works and LOAD-DOMAINS FAILS
security-policy:load-domains('db1'). // Success
// ... You can call LOAD-DOMAINS multiple times
security-policy:register-domain('common', 'common','domain description'). // fails with 14560 'SECURITY-POLICY:REGISTER-DOMAIN failed because the registry is already locked'

Teodor, is this ready to be merged?

Lorian, please test this task according to Customer_Test_Plan_Tracking

I have already tested this and it passed.

I think it can be merged to trunk