I repeat, these are not acceptable tests. Please make the appropriate corrections to them. Turn these into actual functional tests, otherwise they have no real purpose.
Rick On Tue, May 17, 2022 at 8:01 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote: > On 17.05.2022 13:37, Rick McGuire wrote: > > This is not an acceptable way to fix these tests. Just removing the > expected error and adding a totally unnecessary tautological assertion is > not enough. These tests need to also verify that the correct method has > been invoked by checking the return value from the method call. > > Two remarks: > > - There were existing tests that expected an error, if the override > was not done to a message to self. These tests would now fail as these > overrides are allowed. So removing the expected error turns the test into > the opposite, testing whether an override is accepted and carried out. If > the override takes place successfully assertTrue(.true) is used to increase > the success assertion counter, otherwise the test suite would not be able > to increase that counter anymore. > > - Ad testing whether the overrides work correctly, i.e. invoking the > expected methods, these tests are the ones that I added explicitly, such > that this aspect gets tested as well for send, sendWith, start, startWith > for both, the .Message and the .Object classes. If you look up these test > groups you will see that the tests include override tests for mixinclasses > where the results of the invoked messages get tested for correctness. It > may be the case that I am missing some tests, if so, please advise. > > ---rony > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
