Should test:assertEquals reflect the language semantic of == and ===

[rdhananjaya]

This discussion expects to continue and conclude the discussion started here #28062 (comment).

As anydata does not contain errors at any depth, we can no longer use == operator (Deep Equal) to compare values that may contain error values. What I want to conclude is whether the assertEquals:

1. Should reflect the semantic of ==.
2. Should have a hybrid of == and === like now.
3. Should compare errors to a custom depth specified by testerina.
4. Have a totally different API(s).

If we are to go with approach one, then the function signature will be something like function assertEquals(anydata actual, anydata expected, string msg = "Assertion Failed!"), with this we can no longer compare values that may contain errors. So I think a typical call to this function will be assertEquals(checkpanic funcThatMayReturnError("123"), 123). If they want to compare errors of values that may contain errors they have to write the assert functions them self.

If we are to go with the current behavior, with the signature of function assertEquals(anydata|error actual, anydata|error expected, string msg = "Assertion Failed!") that is to perform deep equals for anydata values and reference equality for non anydata values. With this signature, this function does not accept arguments which may contain an error as one of its members. In my view this significantly limit the usage of this function. And a user almost can never compare two erros to be equal, say one from the actual test case vs a mocked error, as they are not reference equal.

Third approach is to compare error values to a depth that testerina defines, something like we compare error message, details, and the cause recursively but does not compare the type-ids of the errors. I think this is the most flexible for a test author, but this defy the language equality semantics for anydata vs any.

And the fourth approach is to introduce a new set of functions to assert values.

[hevayo]

We can consider changing the APIs so we can keep the ease of use
ie. assertEquals(anydata | error actual, anydata expected) If the function throws an error it will panic.
assertExactEquals(any | error actual, any | error expected) can remain the same for === WDYT ?

[rdhananjaya]

will update the PR with this.