Add AssertNot* methods

[beslst]

Some unit tests require to assert for the opposite condition, e.g. AssertArray2dNotEquals_LREAL

@sagatowski this would require a lot of duplicated code. If I would implement this, would you suggest to try to avoid code duplication or just go for it? Avoiding duplication would mean a lot of refactoring of the existing code base

[sagatowski]

Hey @iadonkey!

Is it possible to simply use AssertFalse() as an option?

[beslst]

In the end I can boil everything down to AssertFalse or AssertTrue, but I was actually talking about these kind of assertions

https://www.javaguides.net/2018/09/junit-5-assertnotequals-example.html?m=1#:~:text=JUnit%205%20Tutorial,-In%20this%20tutorial&text=The%20assertNotEquals()%20method%20asserts,null%2C%20they%20are%20considered%20equal.

using AssertTrue or AssertFalse does not give good informations in the assertion message

[sagatowski]

Aha, I've missed that. I've only used JUnit 4.
In the use-cases where I've needed to check for a NOT (like a string is not empty) I've simply done AssertTrue(Condition := MyString <> '');
What is your expected output of a failed AssertNot? What does the output from JUnit 5 say if an AssertNot fails?
The default message provided by FB_AdsAssertMessageFormatter.LogAssertFailure() won't most likely cut it.
If we change this, this will also have an impact on TcUnit-Runner, as it expects the output-string to look in a certain way.

[beslst]

Yes, without some refactoring this would be a lot of code duplication as well. Also, ofc you can bypass the need for it by using AssertTrue/AssertFalse with the disadvantages of losing the automatic expected and actual output message.

Junit5 writes something along those lines
“AssertionFailedError: expected: not "Hello" but was: "Hello"”, I’ll check for more examples next week, this is just from the top of my head.

The actual use cases I got are

• matrix calculations where it would be most useful (as writing out the AssertTrue fallback is tedious)
• Checking for IDs, e.g. when automatically incrementing static counters for function blocks to assign a unique id to them check if the instances have different IDs.

It is not a very important feature, but more or less for the sake of completeness.

[sagatowski]

I agree, the AssertNot makes a lot of sense and it's a great idea. Some of the tests I've seen (including my own ones) would be cleaner with an AssertNot.

You've made me walk into the path of installing the JDK and playing around a little bit with JUnit 5 to get a little bit of feeling of how it's handled there.
I've included the AssertNot-functionality into the plan for TcUnit 1.4, as I'm planning to release 1.3 before new year and this will most likely not make it to 1.3.

[sagatowski]

Managed to get JUnit 5 running and wrote a single test.

First a classical (failing) AssertEquals on string results in:

Then a (failing) AssertNotEquals on string results in:

[sagatowski]

I realize that JUnit5 manages messages quite differently than TcUnit.

If I add a "Message" of "This failed!" to the AssertEquals, I get:

If I add a "Message" of "This failed!" to the AssertNotEquals, I get:

So it seems they simply replace the "Values should be different" with the user-customized message.
In TcUnit we always print the message (as MSG: xyz), unless a message is not provided, in which case this is not included. But it does not replace any text.

Have to think of something that makes sense for TcUnit.