More readable and typically more efficient.
Change-Id: I9bd5bfc91f4ac255bb8ae0987708fb8b56b398f8
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/95285
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Because the new-style tests are intrustive,
the exception that CppUnit throws on assertion
failures is caught and processed with the
application logic, which is far from ideal,
because it's very difficult to find the
cause of failure.
What we'd like is a way to control what happens
when an test assertion fails, such that we can
properly log/print the failure, and even break
in the debugger.
The new macros allow us to control the behavior
at compile-time and have added flexibility.
For now, they log an assertion failure before
invoking the CPPUNIT macro, and support a
compile-time directive to assert, which is
useful for breaking in the debugger.
Change-Id: If464ba246e3ec747f31496a4215cb73ef735dfaf
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/87625
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Actually, I should expand on this and write a test that makes sure the
FakeSocket API semantics does in fact match that of the real socket
API... A fakefakesockettest. Later.
Change-Id: I5cf885a956d6d795976a4369448be04e88837c19
I had no idea that the CPPUNIT_ASSERT* macros work by throwing
exceptions. They do, so one should thus not catch them, but let the
Cppunit code take care of that.
Also, make the tests a bit more specific and add some
fakeSocketAvailableDataLength() checks.
Change-Id: I9291822114331c21b774bb41116e8b2ff709dae2
Based on Mobile/TestFakeSocket/TestFakeSocket/main.mm. Needs work,
does not really test the interesting semantic corner cases that have
been fixed only recently.
Change-Id: Ie2f3dbd2b478ab3acb4bfef0e0d3031c817d0f37
