strepsirrhini/libreoffice-online
3
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
libreoffice-online/test/lokassert.hpp

88 lines
5.4 KiB
C++
Raw Normal View History

wsd: test assertion macros 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>
2020-01-20 10:45:53 -06:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4; fill-column: 100 -*- */
/*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*/
Use #pragma once LibreOffice core uses that, too, and we support an even more restricted set of compilers. Change-Id: I0d0e2c8608e323eb5ef0f35ee8c46d02ab49a745 Reviewed-on: https://gerrit.libreoffice.org/c/online/+/92467 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-04-18 03:39:50 -05:00
#pragma once
wsd: test assertion macros 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>
2020-01-20 10:45:53 -06:00
wsd: test: leverage the log system in TST_LOG This moves the test log macros into a new home, test/testlog.hpp, to avoid cycling dependencies. Change-Id: Iacb80e813a64ff830fa18f63ec4de2535ee702b7 Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
2020-12-20 17:35:31 -06:00
#include "testlog.hpp"
wsd: test assertion macros 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>
2020-01-20 10:45:53 -06:00
#include <assert.h>
#include <cppunit/extensions/HelperMacros.h>
inline std::ostream& operator<<(std::ostream& os, const std::vector<char>& v)
{
wsd: avoid the using keyword and use C++ size_t size_t in C and in C++ are not necessarily the same type. The C++ size_t is in the std namespace. Since we do include many C headers, and indeed some C++ runtime headers do define size_t for backwards compatibility, it's easy to mix and match the two types. Also, 'using std::size_t;' isn't a great practice, so removed. This is not exhaustive, just some low-hanging cases. Change-Id: I85a36b6fd1acd204274b1869de9bcb94c8b3cf13 Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
2020-11-15 11:03:45 -06:00
const std::size_t size = v.size();
wsd: test assertion macros 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>
2020-01-20 10:45:53 -06:00
if (size <= 32)
os << std::string(v.data(), size);
else
os << std::string(v.data(), 32) << "...";
return os;
}
#ifdef LOK_ABORT_ON_ASSERTION
#define LOK_ASSERT_IMPL(X) assert(X);
#else
#define LOK_ASSERT_IMPL(X)
Fix comment Change-Id: I726f3cd30a9a7d393a414efbaebabdc1807f4ecc Reviewed-on: https://gerrit.libreoffice.org/c/online/+/92388 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-04-16 06:14:23 -05:00
#endif //LOK_ABORT_ON_ASSERTION
wsd: test assertion macros 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>
2020-01-20 10:45:53 -06:00
#define LOK_ASSERT(condition) \
do \
{ \
if (!(condition)) \
{ \
wsd: test: log test assertions Change-Id: Ibf9274b1812f70f54ccd4e7be991b08a11f36c86 Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
2020-12-22 18:08:45 -06:00
TST_LOG_NAME("unittest", "Assertion failure: " << (#condition)); \
wsd: test assertion macros 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>
2020-01-20 10:45:53 -06:00
LOK_ASSERT_IMPL(condition); \
CPPUNIT_ASSERT(condition); \
} \
} while (false)
#define LOK_ASSERT_EQUAL(expected, actual) \
do \
{ \
if (!((expected) == (actual))) \
{ \
wsd: test: log test assertions Change-Id: Ibf9274b1812f70f54ccd4e7be991b08a11f36c86 Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
2020-12-22 18:08:45 -06:00
TST_LOG_NAME("unittest", "Assertion failure: Expected [" \
<< (expected) << "] but got [" << (actual) << ']'); \
wsd: test assertion macros 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>
2020-01-20 10:45:53 -06:00
LOK_ASSERT_IMPL((expected) == (actual)); \
CPPUNIT_ASSERT_EQUAL((expected), (actual)); \
} \
} while (false)
#define LOK_ASSERT_EQUAL_MESSAGE(message, expected, actual) \
do \
{ \
if (!((expected) == (actual))) \
{ \
wsd: test: log test assertions Change-Id: Ibf9274b1812f70f54ccd4e7be991b08a11f36c86 Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
2020-12-22 18:08:45 -06:00
TST_LOG_NAME("unittest", "Assertion failure: " << (message) << ". Expected [" \
<< (expected) << "] but got [" \
<< (actual) << "]: "); \
wsd: test assertion macros 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>
2020-01-20 10:45:53 -06:00
LOK_ASSERT_IMPL((expected) == (actual)); \
CPPUNIT_ASSERT_EQUAL_MESSAGE((message), (expected), (actual)); \
} \
} while (false)
#define LOK_ASSERT_MESSAGE(message, condition) \
do \
{ \
if (!(condition)) \
{ \
wsd: test: log test assertions Change-Id: Ibf9274b1812f70f54ccd4e7be991b08a11f36c86 Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
2020-12-22 18:08:45 -06:00
TST_LOG_NAME("unittest", \
"Assertion failure: " << (message) << ". Condition: " << (#condition)); \
wsd: test assertion macros 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>
2020-01-20 10:45:53 -06:00
LOK_ASSERT_IMPL(condition); \
CPPUNIT_ASSERT_MESSAGE((message), (condition)); \
} \
} while (false)
#define LOK_ASSERT_FAIL(message) \
do \
{ \
wsd: test: log test assertions Change-Id: Ibf9274b1812f70f54ccd4e7be991b08a11f36c86 Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
2020-12-22 18:08:45 -06:00
TST_LOG_NAME("unittest", "Forced failure: " << (message)); \
LOK_ASSERT_IMPL(!"Forced failure"); \
wsd: test assertion macros 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>
2020-01-20 10:45:53 -06:00
CPPUNIT_FAIL((message)); \
} while (false)
Reference in a new issue Copy permalink