Feature #8676
ABLUnit assert error messages are different in different OE versions
0%
History
#1 Updated by Greg Shah 10 days ago
Marian's team has written a large number of ABLUnit tests which relied upon OE (12.x?) error messages from the assert implementation. When ABLUnit was implemented in #3827, these messages were changed to match a different iteration of the 4GL code (11.x?). This breaks a large number of their tests.
Considering that we have multiple customers with large sets of tests, I think this is an area where we need to provide runtime compatibility with different 4GL versions. This can be achieved using EnvironmentOps.versionNumber() or one of the helpers from EnvironmentOps. In other words, we should allow the configuration of the OE compatibility level in the directory and then honor that level in our assert implementation so that all tests can be made to work properly.
Marian: Please provide some more details on the specific changes that need to be made. Also, please post some example tests that are broken.
#2 Updated by Marian Edu 8 days ago
Greg Shah wrote:
Marian: Please provide some more details on the specific changes that need to be made. Also, please post some example tests that are broken.
This is one example:
tests/oo/openedge/net/server_connection/client_socket/quirks/TestConstructorClSkConnParamQuirk.cls
Basically the assertion message in OE12.2 say '[Arg] cannot be null' while in now FWD it's '[Arg] cannot be unknown' - oddly enough this 'unknown' message was used only for methods taking character/longchar as input for all others they've used 'null'. This seems to have changed in latest version (12.8) and it's 'unknown' all over as far as I can tell.
#3 Updated by Marian Edu 8 days ago
A quick search on testcases project shows we have 500 asserts on 'not null' error messages, for some tests of #6410 we've separated the test for exact error message in 'quirks' just to get the tests to pass in FWD but this is just a waste of time imho :(
It probably worth nothing that in 4GL there is no `OpenEdge.Core.AbstractAssert` class, extending static classes is also a question of taste :)
If we are to use the OE version number here, all other OO implementation as a matter of fact, it's not only hard to find out on which OE version the change belongs but the FWD code will became very hard to read and possibly maintain. It would have been easier if this would have been in a separate project and maintain different versions of it then simply deploy the version used by the client.