Coder Social home page Coder Social logo

unittest-cpp's Introduction

Maintenance of UnitTest++, recently sporadic, is officially on hiatus until 26 November 2020. Subscribe to #180 for updates.

Build Status Build status

UnitTest++

UnitTest++ is a lightweight unit testing framework for C++. It was designed to do test-driven development on a wide variety of platforms. Simplicity, portability, speed, and small footprint are all very important aspects of UnitTest++. UnitTest++ is mostly standard C++ and makes minimal use of advanced library and language features, which means it should be easily portable to just about any platform. Out of the box, the following platforms are supported:

  • Windows
  • Linux
  • Mac OS X

Documentation

The full documentation for building and using UnitTest++ can be found on the GitHub wiki page. The contents of this wiki are also included as a git submodule under the docs folder, so version-specific Markdown documentation is always available along with the download.

Pre-requisites

While there are currently some bundled automake files, UnitTest++ is primarily built and supported using CMake.

Downloading

Latest (HEAD)

Via git:

git clone https://github.com/unittest-cpp/unittest-cpp

Via svn:

svn checkout https://github.com/unittest-cpp/unittest-cpp/trunk unittest-cpp

Latest release (v2.0.0)

Via git:

git clone https://github.com/unittest-cpp/unittest-cpp
cd unittest-cpp
git checkout v2.0.0

Via svn:

svn checkout https://github.com/unittest-cpp/unittest-cpp/tags/v2.0.0 unittest-cpp

License

UnitTest++ is free software. You may copy, distribute, and modify it under the terms of the License contained in the file LICENSE distributed with this package. This license is the same as the MIT/X Consortium license.

Contributors

Current Maintainers:

Original Authors:

Contributors not included in github history

  • Jim Tilander
  • Kim Grasman
  • Jonathan Jansson
  • Dirck Blaskey
  • Rory Driscoll
  • Dan Lind
  • Matt Kimmel -- Submitted with permission from Blue Fang Games
  • Anthony Moralez
  • Jeff Dixon
  • Randy Coulman
  • Lieven van der Heide

Historic release notes

Version 2.0.0 (2017-01-13)

  • Change Check method supporting CHECK macro to accept argument by reference
  • Introduce long macro forms (e.g. UNITTEST_CHECK); make short forms optional
  • Improved Visual Studio 2015 support
  • Full List

Version 1.6.0 (2016-02-29)

  • Add REQUIRE macro to end tests early when selected checks fail
  • Full List

Version 1.5.1 (2016-01-30)

  • pkg-config support
  • Fix for Visual Studio 2010 compilation issue in 1.5.0
  • Full List

Version 1.5 (2015-11-04)

  • Visual Studio 2015 support
  • CMake-based build management
  • Integration of SourceForge and Google Code versions of the project
  • Full List

Version 1.4 (2008-10-30)

  • CHECK macros work at arbitrary stack depth from inside TESTs.
  • Remove obsolete TEST_UTILITY macros
  • Predicated test execution (via TestRunner::RunTestsIf)
  • Better exception handling for fixture ctors/dtors.
  • VC6/7/8/9 support

Version 1.3 (2007-4-22)

  • Removed dynamic memory allocations (other than streams)
  • MinGW support
  • Consistent (native) line endings
  • Minor bug fixing

Version 1.2 (2006-10-29)

  • First pass at documentation.
  • More detailed error crash catching in fixtures.
  • Standard streams used for printing objects under check. This should allow the use of standard class types such as std::string or other custom classes with stream operators to ostream.
  • Standard streams can be optionally compiled off by defining UNITTEST_USE_CUSTOM_STREAMS in Config.h
  • Added named test suites
  • Added CHECK_ARRAY2D_CLOSE
  • Posix library name is libUnitTest++.a now
  • Floating point numbers are postfixed with 'f' in the failure reports

Version 1.1 (2006-04-18)

  • CHECK macros do not have side effects even if one of the parameters changes state
  • Removed CHECK_ARRAY_EQUAL (too similar to CHECK_ARRAY_CLOSE)
  • Added local and global time constraints
  • Removed dependencies on strstream
  • Improved Posix signal to exception translator
  • Failing tests are added to Visual Studio's error list
  • Fixed Visual Studio projects to work with spaces in directories

Version 1.0 (2006-03-15)

  • Initial release

unittest-cpp's People

Contributors

edanaher avatar flow86 avatar gabrielhare avatar grahamreeds avatar hymerman avatar iblislin avatar jasonhorsburgh avatar jonchesterfield avatar killoctal avatar korli avatar locutusofborg avatar magicant avatar martinmoene avatar nlap avatar ohz10 avatar paleozogt avatar pjohnmeyer avatar qdii avatar rioki avatar rmpowell77 avatar timdave13 avatar vicentebolea avatar warmist avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

unittest-cpp's Issues

AUTHORS out of sync with readme

Hi,

just a minor thing, but while looking through the repo I noticed the text about the fork in AUTHORS seems outdated and is contradicting whats told in the readme.md .
Same may apply to an email given inside configure.ac .

Continuous integration

I think we should set up CI using Travis (for linux) and AppVeyor (for Windows). I'm quite happy to do the work (I've just done it for another project); I just thought I'd create an issue before I start to make sure I'm not treading on anyone's toes!

TestReporterStdout::ReportSummary discrepancy between declaration and definition

From http://code.google.com/p/unittestpp/issues/detail?id=8

A proprietary compiler that we're using is generating a warning on
TestReporterStdout::ReportSummary, because the header declaration does not exactly match the
source definition.

TestReporterStdout.h:

virtual void ReportSummary(
  int totalTestCount, int failedTestCount, int failureCount, float secondsElapsed);

TestReporterStdout.cpp:

void TestReporterStdout::ReportSummary(
  int const totalTestCount, int const failedTestCount, int const failureCount, float secondsElapsed)

Notice the extra "const"s in the definition. Even though they're arguably compatible, it's a bit of a
gray area. Even MSVC will complain in some cases when function signatures differ by a const
qualifier.

The simple fix is just to remove the consts in this cpp file.

Destructor throws exception

In tests/TestTestMacros.cpp,
I found this:

struct FixtureDtorThrows
{
    ~FixtureDtorThrows() { throw "exception"; }
};

This is quite intriguing, but I don’t know the code very well, so it might just be a false-positive. Anyone known more?

Including project files within the project tree

UnitTest++ has had CMake support for a while now, which allows users to generate projects for a wide variety of build systems. However, this can be seen as an obstacle to potential users; CMake is yet another dependency that they don't want to take on, yet another tool to learn, etc.

In version 1.4, a simple Makefile, Visual Studio 2003, and Visual Studio 2005 projects were provided.

There has been some discussion in pulls #31 and #40 regarding how best to support the myriad of build systems out there. I see a few paths forward, and I am looking to the users to help decide.

1) Eliminate all build files from the tree aside from CMake

CMake is the one true build system for UnitTest++. Clean house. There is no Dana only Zuul. This makes maintenance easy.

2) Officially support only the CMake files, but blindly accept community pulls providing other build files

Project files are included in the master line. Issues with them are to be labeled as enhancements. Pull requests updating/adding project files would be accepted without any review. Maintenance remains easy, but files can fall out of date and end up broken.

3) Support build files as 'add-ons' per #13

Works in conjunction with option 1), or as a method of implementing 2). Additional contributors can be given access to keep files up-to-date without main project maintainers having to approve a pull. Files can again fall out of date, but will not clutter up the main repo.

4) CMake in master, CMake + build files in 'releases'

Master line will be like 1). A reasonable number of build systems will be supported as part of generating a release tag. (Historically, releases have been few and far between with UnitTest++, though, and I don't know how this will trend in the future.)

Any and all feedback / additional options are welcome.

Cannot build with build the lib with arm-elf-g++

From http://code.google.com/p/unittestpp/issues/detail?id=16

What steps will reproduce the problem?

  1. make CXX=arm-elf-g++ clean all // this on the given example of UnitTest++

What is the expected output? What do you see instead?
I expect:
**** Build of configuration Default for project UnitTest++ ****

make clean all
src/AssertException.cpp
src/Test.cpp
src/Checks.cpp
src/TestRunner.cpp
src/TestResults.cpp
src/TestReporter.cpp
src/TestReporterStdout.cpp
src/ReportAssert.cpp
src/TestList.cpp
src/TimeConstraint.cpp
src/TestDetails.cpp
src/MemoryOutStream.cpp
src/DeferredTestReporter.cpp
src/DeferredTestResult.cpp
src/XmlTestReporter.cpp
src/CurrentTest.cpp
src/Posix/SignalTranslator.cpp
src/Posix/TimeHelpers.cpp
Creating libUnitTest++.a library...
src/tests/Main.cpp
src/tests/TestAssertHandler.cpp
src/tests/TestChecks.cpp
src/tests/TestUnitTest++.cpp
src/tests/TestTest.cpp
src/tests/TestTestResults.cpp
src/tests/TestTestRunner.cpp
src/tests/TestCheckMacros.cpp
src/tests/TestTestList.cpp
src/tests/TestTestMacros.cpp
src/tests/TestTimeConstraint.cpp
src/tests/TestTimeConstraintMacro.cpp
src/tests/TestMemoryOutStream.cpp
src/tests/TestDeferredTestReporter.cpp
src/tests/TestXmlTestReporter.cpp
src/tests/TestCurrentTest.cpp
Linking TestUnitTest++...
Running unit tests...
Success: 174 tests passed.
Test time: 0.10 seconds.

I get:
$ make CXX=arm-elf-gcc clean all
make: [clean] Error 1 (ignored)
src/AssertException.cpp
src/Test.cpp
src/Checks.cpp
src/TestRunner.cpp
src/TestRunner.cpp: In constructor UnitTest::TestRunner::TestRunner(UnitTest::TestReporter&)': src/TestRunner.cpp:24: error: invalid use of undefined typestruct
UnitTest::Timer'
src/TestRunner.h:12: error: forward declaration of struct UnitTest::Timer' src/TestRunner.cpp:26: error:Start' undeclared (first use this function)
src/TestRunner.cpp:26: error: (Each undeclared identifier is reported only once
for each function it appears in.)
src/TestRunner.cpp: In destructor UnitTest::TestRunner::~TestRunner()': src/TestRunner.cpp:32: warning: possible problem detected in invocation of delete operator: src/TestRunner.cpp:32: warning: invalid use of undefined typestruct
UnitTest::Timer'
src/TestRunner.h:12: warning: forward declaration of struct UnitTest::Timer' src/TestRunner.cpp:32: note: neither the destructor nor the class-specific operator delete will be called, even if they are declared when the class is defined. src/TestRunner.cpp: In member functionint UnitTest::TestRunner::Finish()
const':
src/TestRunner.cpp:37: error: GetTimeInMs' undeclared (first use this function) src/TestRunner.cpp: In member functionvoid
UnitTest::TestRunner::RunTest(UnitTest::TestResults_, UnitTest::Test_, int)
const':
src/TestRunner.cpp:56: error: aggregate `UnitTest::Timer testTimer' has
incomplete type and cannot be defined
make: *** [src/TestRunner.o] Error 1

What version of the product are you using? On what operating system?
the latest UniTest-cpp 1.4

Please provide any additional information below.
The idea is to use the unit tests in embedded environment. I'm using:
NXP LPC2214 ARM7TDMI, eCosCentric, arm-elf-gcc (GCC) 4.3.2.
The first run shown was under Linux, with gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Thank you in advance for any help.
Florian

TestUnitTest++.exe Abort() called

Compiling UnitTest++ with Visual Studio 2015 Community Edition. Warning C4297 is triggered by TestTestMacros.cpp line 141.

The key phrase in the MSDN documentation is that VS2015 is adding an implicit noexcept on all user destructors and deallocators. Throwing from a noexcept method causes abort() to be called on the process.

We can add the /Zc:implicitNoexcept when compiling to suppress the implicit noexcept behavior, but going forward I wonder if this is a valid test for C++11 code.

Warnings when building on clang 3.7 with -Wsign-conversion

I see this when I build:

GSL/tests/unittest-cpp/UnitTest++/Posix/TimeHelpers.cpp:30:15: warning: implicit conversion changes
signedness: 'int' to 'useconds_t' (aka 'unsigned int') [-Wsign-conversion]
usleep(ms * 1000);
~~~~~~ ~~~^~~~~~
1 warning generated.

I have a fix in pull request #87

CHECK_THROW should return catched exception

It would be nice if CHECK_THROW macro returned the catched exception making the following possible

auto ex = CHECK_THROW(parse("0xPQ"), ParserException);
CHECK_EQUAL("syntax error", ex.what());

Provide a shared library

Hi,

Would you consider building a shared library alongside the .a archive?
If yes, please include a soname to your library as well.

Thank you,
François Cami (Fedora packager)

Add catch (std::exception &) blocks added to CHECK_*** macros

From https://sourceforge.net/tracker/?func=detail&aid=2918204&group_id=158151&atid=806686:

To avoid losing std::exception::what() info when an expression inside CHECK() or the operator==() itself throw it seems more user-friendly to retain what() message as the cause of failure. See dev list discussion thread "chaining exceptions in CHECK_*** macros?".

The patch generates the original failure message followed by ", cause: " + e.what() and is relative to svnroot/unittest-cpp/UnitTest++

Also, a typo CHECK_ARRAY_CLOSE -> CHECK_ARRAY2D_CLOSE corrected.

Investigate updating C++ REST SDK (Casablanca) to latest UnitTest++ release

Microsoft's C++ REST SDK relies on a very old revision of UnitTest++, copied into the project. This is fine if actually desired, but #72 suggested a sync-up would be worthwhile.

Somebody should take a whirl at incorporating UnitTest++ latest into their project and submit a pull request.

This would be easiest to accomplish after #81 is resolved, since we could then just pull it in via NuGet, but the investigation could be done more informally.

Cannot link with clang

When linking to the unittest-cpp library with clang, I get the following errors:

Undefined symbols for architecture x86_64:
  "std::string::c_str() const", referenced from:
      UnitTest::MemoryOutStream::GetText() const in libUnitTest++.a(MemoryOutStream.cpp.o)
  "std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::str() const", referenced from:
      UnitTest::MemoryOutStream::GetText() const in libUnitTest++.a(MemoryOutStream.cpp.o)
      UnitTest::MemoryOutStream::Clear() in libUnitTest++.a(MemoryOutStream.cpp.o)
  "std::basic_ostream<char, std::char_traits<char> >::~basic_ostream()", referenced from:
      construction vtable for std::ostream-in-UnitTest::MemoryOutStream in libUnitTest++.a(TestRunner.cpp.o)
      construction vtable for std::ostream-in-UnitTest::MemoryOutStream in libUnitTest++.a(Test.cpp.o)
  "std::basic_ostream<char, std::char_traits<char> >::~basic_ostream()", referenced from:
      construction vtable for std::ostream-in-UnitTest::MemoryOutStream in libUnitTest++.a(TestRunner.cpp.o)
      construction vtable for std::ostream-in-UnitTest::MemoryOutStream in libUnitTest++.a(Test.cpp.o)
  "std::ostream::operator<<(double)", referenced from:
      UnitTest::TestRunner::RunTest(UnitTest::TestResults*, UnitTest::Test*, int) const in libUnitTest++.a(TestRunner.cpp.o)
  "std::ostream::operator<<(int)", referenced from:
      UnitTest::TestRunner::RunTest(UnitTest::TestResults*, UnitTest::Test*, int) const in libUnitTest++.a(TestRunner.cpp.o)
  "std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string()", referenced from:
      UnitTest::MemoryOutStream::MemoryOutStream() in libUnitTest++.a(TestRunner.cpp.o)
      UnitTest::MemoryOutStream::MemoryOutStream() in libUnitTest++.a(Test.cpp.o)
      UnitTest::MemoryOutStream::Clear() in libUnitTest++.a(MemoryOutStream.cpp.o)
  "std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()", referenced from:
      UnitTest::MemoryOutStream::~MemoryOutStream() in libUnitTest++.a(TestRunner.cpp.o)
      UnitTest::MemoryOutStream::~MemoryOutStream() in libUnitTest++.a(Test.cpp.o)
      UnitTest::MemoryOutStream::GetText() const in libUnitTest++.a(MemoryOutStream.cpp.o)
      UnitTest::MemoryOutStream::Clear() in libUnitTest++.a(MemoryOutStream.cpp.o)
  "std::string::operator=(std::string const&)", referenced from:
      UnitTest::MemoryOutStream::GetText() const in libUnitTest++.a(MemoryOutStream.cpp.o)
      UnitTest::MemoryOutStream::Clear() in libUnitTest++.a(MemoryOutStream.cpp.o)
  "std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::str(std::string const&)", referenced from:
      UnitTest::MemoryOutStream::Clear() in libUnitTest++.a(MemoryOutStream.cpp.o)
  "std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::basic_ostringstream(std::_Ios_Openmode)", referenced from:
      UnitTest::MemoryOutStream::MemoryOutStream() in libUnitTest++.a(TestRunner.cpp.o)
      UnitTest::MemoryOutStream::MemoryOutStream() in libUnitTest++.a(Test.cpp.o)
  "std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_ostringstream()", referenced from:
      construction vtable for std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >-in-UnitTest::MemoryOutStream in libUnitTest++.a(TestRunner.cpp.o)
      construction vtable for std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >-in-UnitTest::MemoryOutStream in libUnitTest++.a(Test.cpp.o)
  "std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_ostringstream()", referenced from:
      construction vtable for std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >-in-UnitTest::MemoryOutStream in libUnitTest++.a(TestRunner.cpp.o)
      construction vtable for std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >-in-UnitTest::MemoryOutStream in libUnitTest++.a(Test.cpp.o)
  "std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_ostringstream()", referenced from:
      UnitTest::MemoryOutStream::MemoryOutStream() in libUnitTest++.a(TestRunner.cpp.o)
      UnitTest::MemoryOutStream::~MemoryOutStream() in libUnitTest++.a(TestRunner.cpp.o)
      UnitTest::MemoryOutStream::MemoryOutStream() in libUnitTest++.a(Test.cpp.o)
      UnitTest::MemoryOutStream::~MemoryOutStream() in libUnitTest++.a(Test.cpp.o)
  "std::basic_ios<char, std::char_traits<char> >::basic_ios()", referenced from:
      UnitTest::MemoryOutStream::MemoryOutStream() in libUnitTest++.a(TestRunner.cpp.o)
      UnitTest::MemoryOutStream::MemoryOutStream() in libUnitTest++.a(Test.cpp.o)
  "std::basic_ios<char, std::char_traits<char> >::~basic_ios()", referenced from:
      UnitTest::MemoryOutStream::MemoryOutStream() in libUnitTest++.a(TestRunner.cpp.o)
      UnitTest::MemoryOutStream::~MemoryOutStream() in libUnitTest++.a(TestRunner.cpp.o)
      UnitTest::MemoryOutStream::MemoryOutStream() in libUnitTest++.a(Test.cpp.o)
      UnitTest::MemoryOutStream::~MemoryOutStream() in libUnitTest++.a(Test.cpp.o)
  "std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)", referenced from:
      UnitTest::TestRunner::RunTest(UnitTest::TestResults*, UnitTest::Test*, int) const in libUnitTest++.a(TestRunner.cpp.o)
      void UnitTest::ExecuteTest<UnitTest::Test>(UnitTest::Test&, UnitTest::TestDetails const&, bool) in libUnitTest++.a(Test.cpp.o)
  "typeinfo for std::ostream", referenced from:
      construction vtable for std::ostream-in-UnitTest::MemoryOutStream in libUnitTest++.a(TestRunner.cpp.o)
      construction vtable for std::ostream-in-UnitTest::MemoryOutStream in libUnitTest++.a(Test.cpp.o)
  "typeinfo for std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >", referenced from:
      typeinfo for UnitTest::MemoryOutStream in libUnitTest++.a(TestRunner.cpp.o)
      construction vtable for std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >-in-UnitTest::MemoryOutStream in libUnitTest++.a(TestRunner.cpp.o)
      typeinfo for UnitTest::MemoryOutStream in libUnitTest++.a(Test.cpp.o)
      construction vtable for std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >-in-UnitTest::MemoryOutStream in libUnitTest++.a(Test.cpp.o)
  "virtual thunk to std::basic_ostream<char, std::char_traits<char> >::~basic_ostream()", referenced from:
      construction vtable for std::ostream-in-UnitTest::MemoryOutStream in libUnitTest++.a(TestRunner.cpp.o)
      construction vtable for std::ostream-in-UnitTest::MemoryOutStream in libUnitTest++.a(Test.cpp.o)
  "virtual thunk to std::basic_ostream<char, std::char_traits<char> >::~basic_ostream()", referenced from:
      construction vtable for std::ostream-in-UnitTest::MemoryOutStream in libUnitTest++.a(TestRunner.cpp.o)
      construction vtable for std::ostream-in-UnitTest::MemoryOutStream in libUnitTest++.a(Test.cpp.o)
  "virtual thunk to std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_ostringstream()", referenced from:
      construction vtable for std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >-in-UnitTest::MemoryOutStream in libUnitTest++.a(TestRunner.cpp.o)
      construction vtable for std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >-in-UnitTest::MemoryOutStream in libUnitTest++.a(Test.cpp.o)
  "virtual thunk to std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_ostringstream()", referenced from:
      construction vtable for std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >-in-UnitTest::MemoryOutStream in libUnitTest++.a(TestRunner.cpp.o)
      construction vtable for std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >-in-UnitTest::MemoryOutStream in libUnitTest++.a(Test.cpp.o)
ld: symbol(s) not found for architecture x86_64

CHECK_EQUAL crashes for large numbers

From http://code.google.com/p/unittestpp/issues/detail?id=21

What steps will reproduce the problem?

  1. Use this test:
    TEST(checkEqualTest) {
    CHECK_EQUAL(DBL_MAX, 0.0);
    }
  2. Run it.
  3. Notice how it crashes. If it doesn't crash on your system, run it in valgrind.

What is the expected output? What do you see instead?

It shouldn't crash.

What version of the product are you using? On what operating system?

v1.4

Please provide any additional information below.

The problem is happening in MemoryOutStream.cpp in FormatToStream :

template<typename ValueType>
void FormatToStream(MemoryOutStream& stream, char const* format, ValueType const& value)
{
    using namespace std;

    char txt[32];
    sprintf(txt, format, value);
    stream << txt;
}

When formatting most numbers the size of txt is sufficient. However, for things like DBL_MAX which has more than 300 digits, this will fall down. The quick fix is to use a large size for txt. The good fix is to use snprintf.

MingW32 CHECK and CHECK_EQUAL (false) freeze/crash Tests

Hi, having some issues trying to write unit tests for my program.
CodeLite and MingW32-4.8.1 in Windows 7 64 bit.

Generate CodeLite project files with cmake gui for Windows. Everything built cleanly with no errors or issues from latest git clone of repo. Latest (HEAD).

I then created my first unit test and tried CHECK(true); To make sure it's working and i get success;

Basic Code:

#include <UnitTest++.h>

SUITE(Tests)
{
    TEST(TestThisNow)
    {
        CHECK(true);
    }
}

// run all tests
int main(int argc, char **argv)
{
    return UnitTest::RunAllTests();
}
Success: 1 tests passed.
Test time: 0.00 seconds.

Press any key to continue.

I then change CHECK(true); -> CHECK(false);

The program just freezes, doesn't return any failure notices.
I then tried:

   CHECK_EQUALS(10,10);  Works
I then changed it to:
   CHECK_EQUALS(10,20);  Freezes again without listing failures

Wonder if I'm missing something or there are issues in the latest repo.

Strongly typed enumeration support

C++11 introduces enum classes which are not implicitly convertible to integers. This stops the standard CHECK_EQUAL etc macros from working.

To fix this you then have to write a streaming operator

std::ostream& operator<<(std::ostream& os, const EnumeratedType& val)
{
os << static_cast<std::underlying_type::type>(val);
return os;
}

or cast to an int in the macro.

CHECK_EQUAL((int)EnumeratedType::OK, (int)actual);

This gets old pretty fast. Is there a possibility of writing some clever template trickery to support enum classes? It could be selectively enabled by detection of c++11.

std::enable_if, std::is_enum look like good starting points.

please sync unittest-cpp with casablanca fork

Hi, since the Debian package is from a dead upstream, and you seems to be the new one, I would like to update the package with your fork.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784665

unfortunately a package I use (casablanca) did a fork with some new classes that makes the package fail to build with your code.
http://casablanca.codeplex.com/SourceControl/latest#Release/tests/common/UnitTestpp/
how do you feel about merging them to your fork?

after that I'll ask Debian to switch to your code :)

JVM hangs on Mac OS X while profiling

I built the profiler from source after installing unittest-cpp from source and specifying the library to link as well as the include directories. I don't think I got any errors from the maven or the underlying make invocation. I got the liblagent dynamic library as expected in my builds directory. I then started my jvm like this:
java -agentpath:/Users/rajiv/honest-profiler/build/liblagent.dylib -jar ~/Downloads/perftest.jar

It says start and then just keeps there forever consuming a ton of cpu till I kill it.
So something like this:

Rajivs-MacBook-Pro:build rajiv$ java -agentpath:/Users/rajiv/honest-profiler/build/liblagent.dylib -jar ~/Downloads/perftest.jar 
Start

My application prints something to the standard line as soon as it starts and I don't see any of that being printed either.

Create NuGet packaging script for UnitTest++ releases

This came up in the discussion of #72.

Success criteria: A single script can be run (probably with the version number as an argument) that will create the NuGet package and optionally upload it.

See: https://www.nuget.org

Thoughts
This may be best managed as a separate repo "add-on", which I would then incorporate into
the unittest-cpp organization.

Allow "asynchronous" unit test -> new Test Macro ?

In my case I need to run tests that trigger a behavior, and then wait for a callback/signal/flag to keep going...
I am using a main loop from another library. I want to trigger some behavior, wait for a few loops, and then check if the result is as expected.
This might even be useful for "true" concurrency with threads, although it s not my goal here...

At the moment I cannot do this with the current Test macros, because they expect a test to be completely included in one function ( void RunImpl() ).

Something that would allow me to implement that behavior would be a Macro like :

#define TEST_FIXTURE_PART(Fixture, Name, Part) TEST_FIXTURE_PART_EX(Fixture, Name, Part, UnitTest::Test::GetTestList())

where TEST_FEATURE_PART_EX defines multiple runImpl like :

std::pair<std::function<bool()>,UnitTest::TimeConstraint> Fixture##Name##Helper::RunImpl##Part()

Ideally I want use this macro like this :

#define ACCEPTABLE_DELAY(60)

TEST_FIXTURE_PART(OfflineSave, ClearSymmetric_Sync, 1)
{
  std::string original_value = "This is my save that I don't want to loose";
  m_save.requestSaveData(original_value);

  return std::make_pair([=]() -> bool{
    m_save.isSaved() && m_saved
  },
  UNITTEST_TIME_CONSTRAINT(ACCEPTABLE_DELAY)
  );
}

TEST_FIXTURE_PART(OfflineSave, ClearSymmetric_Sync, 2)
{
  m_save.requestLoadData();

  return std::make_pair([=]() -> bool{
    m_save.isLoaded() && m_loaded
  },
  UNITTEST_TIME_CONSTRAINT(ACCEPTABLE_DELAY)
  );
}

TEST_FIXTURE_PART(OfflineSave, ClearSymmetric_Sync, 3)
{
  std::string loaded_value = m_save.getData();    
  CHECK(original_value == loaded_value);
}

Please note in here that the Fixture is the same instance in every test part.
Also now you can see each test part returns both a lambda function to run ( to evaluate when it s suitable to run the next test part ), and a time limit for this condition to be met ( or the test will fail ).

In between each part, the rest of the code can run ( main update loop, and so on... ), via a new Runner that can identify there are multiple parts to this test ( using the return value of runImpl() )

I tried to implement such a feature, but honestly I am not familiar with unittest-cpp code yet and the macros makes it difficult to debug my new code...
So I was wondering :

  • Is this feature doable / suitable for unittest-cpp or not ?
  • If not, am I looking at it the wrong way and there is another/better way to do that ?

Regressions from 1.4

It is nice to know that work is done on UnitTest++, but there where some regressions from 1.4 that I would like to address.

Central Header

The central header used to be UnitTest++.h. It resided in src and I would normally copy them to $(prefix)/UnitTest++. The header is now named unittestpp.h and is located in the root folder. This would be no big issue if the header would not include src bit in the include directives. This complicated the installation tremendously.

config.h

This is similar to the central header. It was moved and now you need to touch each file to create a IMO clean install.

Custom Streams

It used to be that the default stream is the standard stream and you could optionally use the custom streams for non standard environments. This behavior was revered and broke most of my unit tests. Sure you can change the behavior back by commenting in UNITTEST_MEMORYOUTSTREAM_IS_STD_OSTRINGSTREAM, but it seems counter intuitive.

One of the features of UnitTest++ was that is just worked. This variant, that is not the case.

Missing builds folder

The wiki page Building UnitTest++ With CMake mentions an empty 'builds' folder. However I don't see one.

Deactivate/redirect older project site on here

Hello,

Having still 2 websites not redirecting to the current site just bring confusion. Those old website should at least have the main page indicating they are obsolete and people should go to github.

And the issue trackers and source code management should be deactivated too

Version 1.5.0 has been tagged

Today I updated all of the version information in the repository and tagged v1.5.0. What does this mean?

  1. For the people out there who need a "release" to work against -- they have it.
  2. I have drawn a line in the history. From this point on the project will be using Semantic Versioning for version numbers.
  3. I will start making tags once a month (potentially more if serious bugs are found), if any changes have been made. The 1.5.1 milestone has been created, but there are no tickets associated with it yet.

I'm going to put out a more thorough update about this, as well as start the discussion about where to go from here, but for tonight this will suffice.

Tests broken in Visual Studio 2010

UnitTest++ fails to compile the tests in Visual Studio 2010, failing in TestTestMacros.cpp at Line 170.

This line has comment preceding it and a preprocessor version check. Basically it says Visual Studio 2015 implicitly adds noexcept to destructors and any exceptions thrown will cause abort to be thrown. The code is surrounded by a #if(_MSC_VER < 1900). I am guessing that _NOEXCEPT_OP macro is supposed to emulate noexcept where support is not available.

However NOEXCEPT_OP is not #defined for MSVC because the definitions (lines 19,21,29 and 31) are surrounded by #ifndef _MSC_VER and so they are never seen.

I am investigating a fix.

3>  TestTestMacros.cpp
3>..\tests\TestTestMacros.cpp(170): error C3646: '_NOEXCEPT_OP' : unknown override specifier
3>..\tests\TestTestMacros.cpp(170): error C2059: syntax error : 'constant'
3>..\tests\TestTestMacros.cpp(170): error C2091: function returns function

CrashingTestsAreReportedAsFailures crashes on OS X 10.8.3 and Xcode 4.6.2

When running the unittests of unittest-cpp on Mac OS X 10.8.3 in Xcode 4.6.2 they crash.

The following errors are reported:
When not attaching a debugger on crash:
libc++abi.dylib: terminate called without an active exception

When attaching lldb on crash:
error: address doesn't contain a section that points to a section in a object file
Second entry of the backtrace: ExecuteTest.h, line 35

When attaching gdb on crash:
Program received signal: "EXC_BAD_ACCESS"
in TestTest.cpp line 85

I tried to add more signal handlers (for SIGABRT and SIGTERM) but they were not called (the breakpoint I set into the handler function didn't trigger - which might be just how the debugger interacts with certain signals).

I'm unsure if the crash provoking code in TestTest.cpp line 85 can be caught via signals as I don't have much experience with them. Therefore I am unsure if this is a bug or expected behavior but wanted to report it should there be a fix for this.

CHECK_EQUAL() explodes if actual==NULL

Copied from https://sourceforge.net/tracker/?func=detail&aid=1844387&group_id=158151&atid=806684

If the "actual" value passed into CHECK_EQUAL is NULL, std::strcmp() will throw an exception in CheckStringsEqual(). Here's is my simple workaround:

void CheckStringsEqual(TestResults& results, char const* expected, char const* actual, TestDetails const& details)
{
  // WAS: if (std::strcmp(expected, actual))
  if (actual == NULL || std::strcmp(expected, actual))
  {
    UnitTest::MemoryOutStream stream;
    // WAS: stream << "Expected " << expected << " but was " << actual;
    stream << "Expected " << expected << " but was " << (actual ? actual : "(null)");
    results.OnTestFailure(details, stream.GetText());
  }
}

There are a few possible patches in the comments of the original bug to consider for incorporation. It should be noted, though, that the test does correctly fail on the CHECK_EQUAL invocation, so I marked this as an enhancement, as opposed to a bug.

Crash in TestUnitTest++.exe

I wanted to try the latest git version and used the cmake-gui program from cmake 3.0.2 to produce a mingw makefile for TDM-gcc-32 4.8.1 .
When I first tried "mingw32-make" and "mingw32-make check" did work flawlessly.
Then I noticed I had forgotten to set CMAKE_BUILD_TYPE inside the cmake gui. So I deleted everything and set it to Release (which sets -O3 -DNDEBUG when compiling), but this time make check crashed with a seg fault.
I repeated that with RelWithDebInfo setting (this sets -O2 -g -DNDEBUG), and got a crash again.
I then started the TestUnitTest++.exe with gdb and got a stacktrace:

(gdb) run
Starting program: C:\prg\lib\unittest-cpp\builds/TestUnitTest++.exe
[New Thread 3812.0xa58]

Program received signal SIGSEGV, Segmentation fault.
0x77c160ad in strcat () from C:\WINDOWS\system32\msvcrt.dll
(gdb) bt
#0  0x77c160ad in strcat () from C:\WINDOWS\system32\msvcrt.dll
#1  0x0022f340 in ?? ()
#2  0x0046b8bd in (anonymous namespace)::TestTimeConstraintMacroComparesAgainstP
reciseActual::RunImpl (this=<optimized out>)
    at ..\tests\TestTimeConstraintMacro.cpp:45
#3  0x004a1606 in UnitTest::ExecuteTest<UnitTest::Test> (testObject=...,
    details=..., isMockTest=<optimized out>) at ../UnitTest++/ExecuteTest.h:33
#4  0x004766aa in UnitTest::Test::Run (
    this=this@entry=0x529540 <(anonymous namespace)::testTimeConstraintMacroComp
aresAgainstPreciseActualInstance>) at ..\UnitTest++\Test.cpp:34
#5  0x00475f73 in UnitTest::TestRunner::RunTest (this=this@entry=0x22ff34,
    result=<optimized out>, curTest=<optimized out>,
    maxTestTimeInMs=<optimized out>) at ..\UnitTest++\TestRunner.cpp:67
#6  0x0047646c in RunTestsIf<UnitTest::True> (suiteName=0x0,
    maxTestTimeInMs=0, predicate=..., list=..., this=0x22ff34)
    at ../UnitTest++/TestRunner.h:39
#7  UnitTest::RunAllTests () at ..\UnitTest++\TestRunner.cpp:17
#8  0x004f6ca0 in main () at ..\tests\Main.cpp:5

So the crash happened somewhere inside the UNITTEST_TIME_CONSTRAINT macro, but when I tried to look at the source files where that call leads to, I saw no probable cause, and the next stack frame shows only ??. Could it be some miscompilation when doing an optimized build?

CHECK macros redefinition

CheckMacros.h has a ifdef to check if
CHECK, CHECK_EQUAL, etc have been already defined.
This gives me problems when some code which links to other libraries (like glog) which have a CHECK macro (but with different definition) are being tested.
Namespaces cant help with preprocessor macros.
How can I work around this?

If the check macros made calls to static methods within a class thats in the UnitTest namespace, maybe this can be solved by calling the static methods instead of macros in such cases.

Consider changing UnitTest::Check signature to take value by const reference.

From https://sourceforge.net/tracker/?func=detail&aid=2604261&group_id=158151&atid=806684

As of v.1.4, UnitTest::Check() takes a value by copy, however, due to copy constructors, calling this function can have side effects. I feel it is preferable to pass the value by reference, e.g.

template <typename Value>
Check (Value const& value) {
return !!value;
}

This appears to be an inconsistency with the changes from r178 on sourceforge.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.