cppunit-devel — CppUnit Developer Mailing List

[Cppunit-devel] Error in CppUnit 1.9.8

[Steffen H. <ste...@we...>]

Hi all,

there seems to be a bug in the UserInterface (testrunner.dll) of CppUnit 1.9.8.

On long running test cases (maybe caused by some sleeps for example) the "Run" button of the UI is blocked.

The problem is, that the "Browse" button is not blocked while tests are running. To reproduce you have to start a long running TestSuite (use some sleeps). While the tests are executed please select a new test from the TreeHierarchyDialog.  After selection the "run" button is enabled again. On activating the "run" button the whole application is getting blocked and is hanging up (need to be killed by task manager).

I hope that this could be fixed with any following version.

Best regards

Steffen

______________________________________________________________________________
WEB.DE MyPage - Ohne Computerkenntnisse in nur 5 Minuten online! Alles
inklusive! Kinderleicht!  http://www.das.ist.aber.ne.lustige.sache.ms/

[Cppunit-devel] linker errors

[<ad...@gu...>]

CPPUnit developers:

Sorry if this isn't the right forum for asking for support, but if it is,
could you please help???

I just downloaded ver. 1.8.0 of CppUnit, followed the directions for running
the HostApp examples, and everything worked fine.  On a Win32 platform with
Visual C++ 6.0, I then attempted to use the TestRunner Gui (as per the
INSTALL-WIN32.txt instructions), but I get linker errors as follows:

Linking...
msvcprtd.lib(MSVCP60D.dll) : error LNK2005: "public: __thiscall
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> >::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >(class
basic_string<char,struct std::char_traits<char>,class std::allocator<char>
>::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> > const &)"
(??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@
Z) already defined in Employ1Test.obj

Since I'm a C++ newbie, I'd just like to know where I should be looking for
problems.  Source code included below:

//__________________________Employ1Test.h_________________________
#ifndef _EMPLOYTEST_H
#define _EMPLOYTEST_H

#include <cppunit/TestCase.h>
#include <cppunit/extensions/HelperMacros.h>

class Employ1Test : public CppUnit::TestCase
{
  CPPUNIT_TEST_SUITE( Employ1Test );
  CPPUNIT_TEST( testCreateEmployee );
  CPPUNIT_TEST( testGetEmployeeName );
  CPPUNIT_TEST_SUITE_END();
protected:
    void testCreateEmployee( void );
    void testGetEmployeeName( void );
};


#endif // _EMPLOYTEST_H

//__________________________Employ1Test.cpp_________________________
#include "Employ1Test.h"
#include "Employ1.h"

CPPUNIT_TEST_SUITE_REGISTRATION( Employ1Test );

//simply verifies the constuctors don't crash the app
void Employ1Test::testCreateEmployee( void )
{
	Employee *e1 = new Employee("Susan","Baker");
	Employee *e2 = new Employee("Robert","Jones");
  CPPUNIT_ASSERT( (int)e2->getCount == (int)2);
}

//verifies the constructors set the properties as expected, and that we can
retrieve the values
void Employ1Test::testGetEmployeeName( void )
{
	Employee *e1 = new Employee("Susan","Baker");
	Employee *e2 = new Employee("Robert","Jones");
	CPPUNIT_ASSERT( e1->getFirstName() == "Susan" );
}

//__________________________Employ1.h_________________________
#ifndef EMPLOY1_H
#define EMPLOY1_H

class Employee
{
public:
	Employee(const char*, const char*); //constructor
	~Employee(); //destructor
	const char *getFirstName() const;
	const char *getLastName() const;

	//static member function
	static int getCount();

private:
	char *firstName;
	char *lastName;

		//static data member
		static int count;
};

#endif

//__________________________Employ1.cpp_________________________
#include <iostream>

using std::cout;
using std::endl;

#include <cstring>
#include <cassert>
#include "employ1.h"

int Employee::count = 0;

int Employee::getCount() {return count;}

Employee::Employee(const char *first, const char *last)
{
	firstName = new char[strlen(first) + 1];
	assert(firstName != 0);
	strcpy(firstName, first);

	lastName = new char[strlen(last) + 1];
	assert(lastName != 0);
	strcpy(lastName, last);

	++count;
	cout << "Employee constructor for " << firstName <<
		' ' << lastName << " called." << endl;

}

Employee::~Employee()
{
	cout << "~Employee() called for " << firstName <<
		' ' << lastName << "." << endl;
	delete [] firstName;
	delete [] lastName;
	--count;
}

const char *Employee::getFirstName() const
{ return firstName; }

const char *Employee::getLastName() const
{ return lastName; }

RE: [Cppunit-devel] Mock C++

[Philippe F. <P....@OB...>]

> > If I understood right, your framework does not look very generic to me,
and
> > requires many manual calls. I think we can do better.
> It is fairly generic: you don't have much restriction in writing your
expectation 
> and you can easily add new one. What you probably mean is that
> it does not automatize the creation of such class.

Yes, I find it not generic in the sense that you have to write everything
yourself. I would like mock to be very easy to use. CppUnit takes something
like half an hour to set-up. And it is complicated. Mock is going to be even
more difficult.


> 
> > To record the called made to a function, we could add a simple macro
just
> > after every function calls. Compilers usually have a __FUNCTION__ that
> > contains the name of the function, so this could be automatic. It would
> gcc does, but I don't remember VC6 providing that.

Just checked, it does not. __LINE__ + __FILE__ will do.

> 
> > record the function being called. Using a dictionnary behind that, you
would
> > be able to store and retrieve specific information about each function
call.
> I could be done, but I have an hard time seing how you would 
> fill that map: you are not in the function 

There would be a record mode and a check mode. In the record mode, all calls
are recorded for future reference. In check mode, an exception is raised if
the function is not called properly and in the right order. In both case, I
am in the function. This is how easymock works I think.

TestTree::testVisitTree()
{
	Tree tree;
	tree.load( "Foo1Foo2Bar1" );	// prepare a tree with two Foo1,
Foo2 and Bar1

	mock = new MockVisitor();

	mock.setRecordMode();
	mock.visitFoo( tree.foo1 ); // is recorded for future comparison
	mock.visitFoo( tree.foo2 ); // is recorded for future comparison
	mock.visitFoo( tree.bar1 );

	mock.setCheckMode();
	
	try {
		tree.visitTree( mock );
	} catch (MockError me ) {
		// display mock error
	}
}


class MockVisitor : Visitor, CppMock
{
	// [...]
	void visitFoo( Foo * foo ) {
		NOTIFY_FUNCTION_CALLED;
		NOTIFY_ARG( foo->toString() );
		END_NOTIFY;
	}

	void visitBar( Bar * bar ) {
		NOTIFY_FUNCTION_CALLED;
		NOTIFY_ARG( bar->toString() );	
		END_NOTIFY;
	}
};

#define NOTIFY_FUNCTION_CALLED notifyFunctionCalled( __FILE__, __LINE__ )
#define NOTIFY_ARG( foo )	notifyArg( foo )
#define END_NOTIFY()		endNotify()

class FunctionCall
{
public:
	std::string file;
	long line;
	std::vector< std::string > args;
}

class Mock
{
public:
	// [...]

	enum MockMode {
		RecordMode,
		CheckMode 
	};

	void notifyFunctionCalled( std::string file, long line ) {
		if (_mode == RecordMode) {
			_currentCall = new FunctionCall;
			_currentCall->line = line;
			_currentCall->file = file;
		} else {
			// retrieve FunctionCall object 
			_expectedCall = getCurrentExpectedCall();

			// check that this function was expected to be
called
			if ( _currentCall->file != _expectedCall->file
				|| _currentCall->line != _currentCall->line
) {
					throw MockException( "Unexpected
method call" );
			}			
		}
	}

	void notifyArg( std::string arg ) {
		if (_mode == RecordMode) {
			_currentCall->args.add( arg ); // I don't know the
syntax but you get the idea
		} else {
			if ( _currentCall->getCurrentArg() != arg ) {
				throw MockException( "Unexpected arg" );
			}
		}
	}

	void endNotify() {
		if (_mode == RecordMode) {
			// store _currentCall
			_functionCalls->add( _currentCall ); // I don't know
the syntax but you get the idea
		} else {
			// increment index so that next call to
getCurrentExpectedCall() returns the next FunctionCall
		}
	}


protected:
	MockMode _mode;
	FunctionCall * _currentCall;
	FunctionCall * _expectedCall;

	std::map< std::string, int > _functionCallIndex;
	std::vector< FunctionCall > _functionCalls;
};

Of course, the syntax is probably not correct and there are more checks to
add. But you get the idea. The advantages with this framework is that it is
very easy to set-up, in comparison with yours. One don't need to add one
store per function. One could add more methods to tell that a function can
be called any number of times, and stuff like that. The drawbacks:
- does not handle return value
- compare objects with their string representation. I agree it is weak, but
I tend to prefer simple implementable stuff than very good but very
difficult to implement solutions. This is in the spirit of XP. :-) If the
developer is aware that string representation is going to be used, he can
provide a sensible one.


> Also notes that in the provided example, I was tracking the
> call sequence for all methods. Sometime you are only 
> interested on some specific method call count. You implement this by using
a specific
> expectation call count for each methods.

This would be easy to provide.

> 
> Also, notes by doing that you're being a lot less generic: you force the
> user to write mock object in a specific way.

Yes, I force the user into a simple mock framework. The problem I have with
your framework is that the developer must set-up everything by himself. I
already have trouble converting my colleagues to test units. If it is too
difficult to use a mock object, they simply won't. Of course, if you do
everything yourself, you have more control.


> 
> > If we assume all objects can be compared using their string
representation,
> > we can store the expected and actual arguments of every function.
>
> Urk. Never do that. String representation should only be used for
diagnostic
> purpose, never for 'business' stuff. I actually do that by providing
functor
> (with default) for equality and string conversion. Equality is a very
> volatile things when writing unit test. Sometime you need strict identity
> (an object can only be equal to itself), sometime you only need a
similarity
> comparison (the objects have the same caracteristic).

I agree but storing an object of any type for further comparison can't be
done in an automated way, as far as I can tell. I want to avoid the user
declaring each store for each argument function. string looks to me like a
nice way to work this around.

I wanted to implement that for my next project but it turns out that I won't
need it. So I'll implement it some other day, when I'll need it. By the
time, anyone is free and encouraged to pick the idea and code it.


	Philippe

[Cppunit-devel] Question about CppUnit on Solaris8

[wangleiyu <wan...@ko...>]

aGVsbG8sIHRoZXNlIHRpbWVzIGknbSAgdXNpbmcgQ3BwVW5pdChSZWxlYXNlIDEuOC4wKSB0byBk
byB1bml0IHRlc3RpbmcuDQoNCk9uIHdpbjIwMDAgJiBsaW51eCwgaXQncyBvayhhbmQgZWFzeSB0
byB1c2UgOikgKSwgYnV0IG9uIHNvbGFyaXM4IGl0IGNvcmUgZHVtcGVkLg0KDQp3aGF0IGkgZGlk
IGlzIGFzIGZvbGxvd2luZzoNCg0KMS4gZ3VuemlwIGNwcHVuaXQtMS44LjAudGFyLmd6DQoyLiB0
YXIgeHZmIGNwcHVuaXQtMS44LjAudGFyDQozLiBjZCBjcHB1bml0LTEuOC4wDQo0LiBjb25maWd1
cmUgICggbm8gb3B0aW9uLCBubyBhcmd1bWVudCkgDQogICAgICAgICAgICAgICh0aGVyZSB3YXMg
YSB3YXJuaW5nLCBhbmQgdGhlIHJlc3VsdCBpcyBhcyBmb2xsb3dpbmcpDQo1LiBtYWtlICAgKG9r
KQ0KNi4gbWFrZSBjaGVjayANCiAgICAgdGhlIHByb2dyYW0gdGhyb3dlZCBhbiBleGNlcHRpb24g
YW5kIHRoZW4gY29yZSBkdW1wZWQgOg0KICAgICBtYWtlICBjaGVjay1URVNUUw0KICAgICBtYWtl
WzNdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9leHBvcnQvaG9tZS9Ub29scy9DcHBVbml0L2NwcHVu
aXQtICAgMS44LjAvZXhhbXBsZXMvaGllcmFyY2h5Jw0KICAgICAuLlRoZSBmb2xsb3dpbmcgdGVz
dCBmYWlscywgdGhpcyBpcyBpbnRlbmRlZDoNCiAgICAgQWJvcnQgLSBjb3JlIGR1bXBlZA0KICAg
ICBGQUlMOiBoaWVyYXJjaHkNCiAgICAgPT09PT09PT09PT09PT09PT09PQ0KICAgICAxIG9mIDEg
dGVzdHMgZmFpbGVkDQogICAgID09PT09PT09PT09PT09PT09PT0NCiAgICAgDQpteSBtYWNoaW5l
IGVudmlyb25tZW50OiBzb2xhcmlzOCAgZ2NjMi45NS4zDQpIb3BlIHlvdXIgaGVscCBhbmQgbG90
cyBvZiB0aGFua3MgOikNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFlvdXJzIHNpbmNlcmVseSANCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgd2FuZ2xlaXl1ICAyMDAyLTA4LTI2DQoNCg0KQ29uZmlndXJhdGlvbiBSZXN1bHQ6DQoNCmNo
ZWNraW5nIGZvciBhIEJTRCBjb21wYXRpYmxlIGluc3RhbGwuLi4gY29uZmlnL2luc3RhbGwtc2gg
LWMNCmNoZWNraW5nIHdoZXRoZXIgYnVpbGQgZW52aXJvbm1lbnQgaXMgc2FuZS4uLiB5ZXMNCmNo
ZWNraW5nIGZvciBtYXdrLi4uIG5vDQpjaGVja2luZyBmb3IgZ2F3ay4uLiBnYXdrDQpjaGVja2lu
ZyB3aGV0aGVyIG1ha2Ugc2V0cyAke01BS0V9Li4uIHllcw0KY2hlY2tpbmcgd2hldGhlciBtYWtl
IHNldHMgJHtNQUtFfS4uLiAoY2FjaGVkKSB5ZXMNCmNoZWNraW5nIGZvciBhIEJTRCBjb21wYXRp
YmxlIGluc3RhbGwuLi4gY29uZmlnL2luc3RhbGwtc2ggLWMNCmNoZWNraW5nIGZvciBnY2MuLi4g
Z2NjDQpjaGVja2luZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dC4uLiBhLm91dA0KY2hl
Y2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3Jrcy4uLiB5ZXMNCmNoZWNraW5nIHdoZXRo
ZXIgd2UgYXJlIGNyb3NzIGNvbXBpbGluZy4uLiBubw0KY2hlY2tpbmcgZm9yIGV4ZWN1dGFibGUg
c3VmZml4Li4uDQpjaGVja2luZyBmb3Igb2JqZWN0IHN1ZmZpeC4uLiBvDQpjaGVja2luZyB3aGV0
aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIuLi4geWVzDQpjaGVja2luZyB3aGV0
aGVyIGdjYyBhY2NlcHRzIC1nLi4uIHllcw0KY2hlY2tpbmcgZm9yIHN0eWxlIG9mIGluY2x1ZGUg
dXNlZCBieSBtYWtlLi4uIEdOVQ0KY2hlY2tpbmcgZGVwZW5kZW5jeSBzdHlsZSBvZiBnY2MuLi4g
Z2NjDQpjaGVja2luZyBmb3IgZysrLi4uIGcrKw0KY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNp
bmcgdGhlIEdOVSBDKysgY29tcGlsZXIuLi4geWVzDQpjaGVja2luZyB3aGV0aGVyIGcrKyBhY2Nl
cHRzIC1nLi4uIHllcw0KY2hlY2tpbmcgZGVwZW5kZW5jeSBzdHlsZSBvZiBnKysuLi4gZ2NjDQpj
aGVja2luZyBidWlsZCBzeXN0ZW0gdHlwZS4uLiBzcGFyYy1zdW4tc29sYXJpczIuOA0KY2hlY2tp
bmcgaG9zdCBzeXN0ZW0gdHlwZS4uLiBzcGFyYy1zdW4tc29sYXJpczIuOA0KY2hlY2tpbmcgZm9y
IGxkIHVzZWQgYnkgR0NDLi4uIC91c3IvY2NzL2Jpbi9sZA0KY2hlY2tpbmcgaWYgdGhlIGxpbmtl
ciAoL3Vzci9jY3MvYmluL2xkKSBpcyBHTlUgbGQuLi4gbm8NCmNoZWNraW5nIGZvciAvdXNyL2Nj
cy9iaW4vbGQgb3B0aW9uIHRvIHJlbG9hZCBvYmplY3QgZmlsZXMuLi4gLXINCmNoZWNraW5nIGZv
ciBCU0QtY29tcGF0aWJsZSBubS4uLiAvdXNyL2Njcy9iaW4vbm0gLXANCmNoZWNraW5nIHdoZXRo
ZXIgbG4gLXMgd29ya3MuLi4geWVzDQpjaGVja2luZyBob3cgdG8gcmVjb2duaXNlIGRlcGVuZGFu
dCBsaWJyYXJpZXMuLi4gcGFzc19hbGwNCmNoZWNraW5nIGNvbW1hbmQgdG8gcGFyc2UgL3Vzci9j
Y3MvYmluL25tIC1wIG91dHB1dC4uLiBvaw0KY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQysrIHBy
ZXByb2Nlc3Nvci4uLiBnKysgLUUNCmNoZWNraW5nIGZvciBkbGZjbi5oLi4uIHllcw0KY2hlY2tp
bmcgZm9yIHJhbmxpYi4uLiByYW5saWINCmNoZWNraW5nIGZvciBzdHJpcC4uLiBzdHJpcA0KY2hl
Y2tpbmcgZm9yIG9iamRpci4uLiAubGlicw0KY2hlY2tpbmcgZm9yIGdjYyBvcHRpb24gdG8gcHJv
ZHVjZSBQSUMuLi4gLWZQSUMNCmNoZWNraW5nIGlmIGdjYyBQSUMgZmxhZyAtZlBJQyB3b3Jrcy4u
LiB5ZXMNCmNoZWNraW5nIGlmIGdjYyBzdGF0aWMgZmxhZyAtc3RhdGljIHdvcmtzLi4uIHllcw0K
Y2hlY2tpbmcgaWYgZ2NjIHN1cHBvcnRzIC1jIC1vIGZpbGUuby4uLiBubw0KY2hlY2tpbmcgaWYg
d2UgY2FuIGxvY2sgd2l0aCBoYXJkIGxpbmtzLi4uIHllcw0KY2hlY2tpbmcgaWYgZ2NjIHN1cHBv
cnRzIC1mbm8tcnR0aSAtZm5vLWV4Y2VwdGlvbnMuLi4geWVzDQpjaGVja2luZyB3aGV0aGVyIHRo
ZSBsaW5rZXIgKC91c3IvY2NzL2Jpbi9sZCkgc3VwcG9ydHMgc2hhcmVkIGxpYnJhcmllcy4uLg0K
KioqIFdhcm5pbmc6IFJlbGVhc2VzIG9mIEdDQyBlYXJsaWVyIHRoYW4gdmVyc2lvbiAzLjAgY2Fu
bm90IHJlbGlhYmx5DQoqKiogY3JlYXRlIHNlbGYgY29udGFpbmVkIHNoYXJlZCBsaWJyYXJpZXMg
b24gU29sYXJpcyBzeXN0ZW1zLCB3aXRob3V0DQoqKiogaW50cm9kdWNpbmcgYSBkZXBlbmRlbmN5
IG9uIGxpYmdjYy5hLiAgVGhlcmVmb3JlLCBsaWJ0b29sIGlzIGRpc2FibGluZw0KKioqIC1uby11
bmRlZmluZWQgc3VwcG9ydCwgd2hpY2ggd2lsbCBhdCBsZWFzdCBhbGxvdyB5b3UgdG8gYnVpbGQg
c2hhcmVkDQoqKiogbGlicmFyaWVzLiAgSG93ZXZlciwgeW91IG1heSBmaW5kIHRoYXQgd2hlbiB5
b3UgbGluayBzdWNoIGxpYnJhcmllcw0KKioqIGludG8gYW4gYXBwbGljYXRpb24gd2l0aG91dCB1
c2luZyBHQ0MsIHlvdSBoYXZlIHRvIG1hbnVhbGx5IGFkZA0KKioqIGBnY2MgLS1wcmludC1saWJn
Y2MtZmlsZS1uYW1lYCB0byB0aGUgbGluayBjb21tYW5kLiAgV2UgdXJnZSB5b3UgdG8NCioqKiB1
cGdyYWRlIHRvIGEgbmV3ZXIgdmVyc2lvbiBvZiBHQ0MuICBBbm90aGVyIG9wdGlvbiBpcyB0byBy
ZWJ1aWxkIHlvdXINCioqKiBjdXJyZW50IEdDQyB0byB1c2UgdGhlIEdOVSBsaW5rZXIgZnJvbSBH
TlUgYmludXRpbHMgMi45LjEgb3IgbmV3ZXIuDQoNCnllcw0KY2hlY2tpbmcgaG93IHRvIGhhcmRj
b2RlIGxpYnJhcnkgcGF0aHMgaW50byBwcm9ncmFtcy4uLiBpbW1lZGlhdGUNCmNoZWNraW5nIHdo
ZXRoZXIgc3RyaXBwaW5nIGxpYnJhcmllcyBpcyBwb3NzaWJsZS4uLiBubw0KY2hlY2tpbmcgZHlu
YW1pYyBsaW5rZXIgY2hhcmFjdGVyaXN0aWNzLi4uIHNvbGFyaXMyLjggbGQuc28NCmNoZWNraW5n
IGlmIGxpYnRvb2wgc3VwcG9ydHMgc2hhcmVkIGxpYnJhcmllcy4uLiB5ZXMNCmNoZWNraW5nIHdo
ZXRoZXIgdG8gYnVpbGQgc2hhcmVkIGxpYnJhcmllcy4uLiB5ZXMNCmNoZWNraW5nIHdoZXRoZXIg
dG8gYnVpbGQgc3RhdGljIGxpYnJhcmllcy4uLiB5ZXMNCmNyZWF0aW5nIGxpYnRvb2wNCmNoZWNr
aW5nIGZvciBkb3h5Z2VuLi4uIG5vDQpjaGVja2luZyBmb3IgY21hdGguLi4geWVzDQpjaGVja2lu
ZyB3aGV0aGVyIHRoZSBjb21waWxlciBzdXBwb3J0cyBSdW4tVGltZSBUeXBlIElkZW50aWZpY2F0
aW9uLi4uIHllcw0KY2hlY2tpbmcgd2hldGhlciB0aGUgY29tcGlsZXIgaW1wbGVtZW50cyBuYW1l
c3BhY2VzLi4uIHllcw0KY2hlY2tpbmcgd2hldGhlciBzdGQ6OnN0cmluZzo6Y29tcGFyZSB0YWtl
cyBhIHN0cmluZyBpbiBhcmd1bWVudCAxLi4uIHllcw0KY2hlY2tpbmcgd2hldGhlciB0aGUgY29t
cGlsZXIgaGFzIHN0cmluZ3N0cmVhbS4uLiB5ZXMNCmNoZWNraW5nIHdoZXRoZXIgdGhlIGxpYnJh
cnkgZGVmaW5lcyBjbGFzcyBzdHJzdHJlYW0uLi4gY2hlY2tpbmcgZm9yIHN0cnN0cmVhbQ0KLi4u
IHllcw0KeWVzDQpjb25maWd1cmU6IGNyZWF0aW5nIC4vY29uZmlnLnN0YXR1cw0KY29uZmlnLnN0
YXR1czogY3JlYXRpbmcgTWFrZWZpbGUNCmNvbmZpZy5zdGF0dXM6IGNyZWF0aW5nIGNwcHVuaXQu
c3BlYw0KY29uZmlnLnN0YXR1czogY3JlYXRpbmcgY3BwdW5pdC1jb25maWcNCmNvbmZpZy5zdGF0
dXM6IGNyZWF0aW5nIHNyYy9NYWtlZmlsZQ0KY29uZmlnLnN0YXR1czogY3JlYXRpbmcgc3JjL2Nw
cHVuaXQvTWFrZWZpbGUNCmNvbmZpZy5zdGF0dXM6IGNyZWF0aW5nIGluY2x1ZGUvTWFrZWZpbGUN
CmNvbmZpZy5zdGF0dXM6IGNyZWF0aW5nIGluY2x1ZGUvY3BwdW5pdC9NYWtlZmlsZQ0KY29uZmln
LnN0YXR1czogY3JlYXRpbmcgaW5jbHVkZS9jcHB1bml0L2V4dGVuc2lvbnMvTWFrZWZpbGUNCmNv
bmZpZy5zdGF0dXM6IGNyZWF0aW5nIGluY2x1ZGUvY3BwdW5pdC91aS9NYWtlZmlsZQ0KY29uZmln
LnN0YXR1czogY3JlYXRpbmcgaW5jbHVkZS9jcHB1bml0L3VpL21mYy9NYWtlZmlsZQ0KY29uZmln
LnN0YXR1czogY3JlYXRpbmcgaW5jbHVkZS9jcHB1bml0L3VpL3F0L01ha2VmaWxlDQpjb25maWcu
c3RhdHVzOiBjcmVhdGluZyBpbmNsdWRlL2NwcHVuaXQvdWkvdGV4dC9NYWtlZmlsZQ0KY29uZmln
LnN0YXR1czogY3JlYXRpbmcgZG9jL01ha2VmaWxlDQpjb25maWcuc3RhdHVzOiBjcmVhdGluZyBk
b2MvRG94eWZpbGUNCmNvbmZpZy5zdGF0dXM6IGNyZWF0aW5nIGV4YW1wbGVzL01ha2VmaWxlDQpj
b25maWcuc3RhdHVzOiBjcmVhdGluZyBleGFtcGxlcy9oaWVyYXJjaHkvTWFrZWZpbGUNCmNvbmZp
Zy5zdGF0dXM6IGNyZWF0aW5nIGV4YW1wbGVzL2NwcHVuaXR0ZXN0L01ha2VmaWxlDQpjb25maWcu
c3RhdHVzOiBjcmVhdGluZyBjb25maWcvY29uZmlnLmgNCmNvbmZpZy5zdGF0dXM6IGNvbmZpZy9j
b25maWcuaCBpcyB1bmNoYW5nZWQNCmNyZWF0aW5nIGluY2x1ZGUvY3BwdW5pdC9jb25maWctYXV0
by5oIC0gcHJlZml4IENQUFVOSVQgZm9yIGNvbmZpZy9jb25maWcuaCBkZQ0KZmluZXMNCg0KDQoN
Cg0KDQoNCg0KDQo=

Re: [Cppunit-devel] Mock C++

[Baptiste L. <gai...@fr...>]

----- Original Message -----
From: "Philippe FREMY" <P....@OB...>
To: <cpp...@li...>
Sent: Wednesday, August 14, 2002 5:59 PM
Subject: RE: [Cppunit-devel] Mock C++


>[...]
>
> Your example is not exactly crystal clear to me. Tell me if I understood
> correctly:
>
> 1. class ProjectBuilder has methods beginGroup(), endGroup() and
> addSouceFile()
Yes.

> 2. to record the call being made, you use the addActual() function
Indeed. _methodCalls is an ExpectationStringSequence. It expect a specific
sequence of string. Since the string added are the method name, a specific
sequence of method call can be specified that way.
>
> 3. to record the arguments of the functions, you use addActual() on
> ExpectationStringSequence that are specific to a function.
Yes, but that's because my arguments are a single string. I could use an
expectation sequence for a specific struct that represents the arguments or
one expectation sequence for each argument.

> 4. the setExpect stuff is here to match expect vs actual
Yes. You use those methods to specify what you expect to happen.

> 5. you do not handle return values.
In that particular case, I did not have any return values. I don't see a
problem handling them. Just like expectation sequence, you store a list of
value that you use at a later time (though I have not yet implemented such
helper for sequence or associative containers).

> If I understood right, your framework does not look very generic to me,
and
> requires many manual calls. I think we can do better.
It is fairly generic: you don't have much restriction in writing your
expectation and you can easily add new one. What you probably mean is that
it does not automatize the creation of such class.

> To record the called made to a function, we could add a simple macro just
> after every function calls. Compilers usually have a __FUNCTION__ that
> contains the name of the function, so this could be automatic. It would
gcc does, but I don't remember VC6 providing that.

> record the function being called. Using a dictionnary behind that, you
would
> be able to store and retrieve specific information about each function
call.
I could be done, but I have an hard time seing how you would fill that map:
you are not in the function and the value returned will unlikely be portable
across compiler. Also notes that in the provided example, I was tracking the
call sequence for all methods. Sometime you are only interested on some
specific method call count. You implement this by using a specific
expectation call count for each methods.

Also, notes by doing that you're being a lot less generic: you force the
user to write mock object in a specific way.

> If we assume all objects can be compared using their string
representation,
> we can store the expected and actual arguments of every function.
Urk. Never do that. String representation should only be used for diagnostic
purpose, never for 'business' stuff. I actually do that by providing functor
(with default) for equality and string conversion. Equality is a very
volatile things when writing unit test. Sometime you need strict identity
(an object can only be equal to itself), sometime you only need a similarity
comparison (the objects have the same caracteristic).

> The only thing I haven't been able to figure out yet is how to handle
return
> values.
I would use something close to the expectation sequence, using a
getExpectedValue() instead of an addActual() method.

>
> I'll read some C++ books and see if I can find a solution.
>
> regards,
>
> Philippe
>

Re: [Cppunit-devel] Cppunit 1.9.8 Stable?

[Baptiste L. <gai...@fr...>]

As far as I remember there is no regression in that version. Though, the
main difference between stable (1.8.0) and unstable version (1.9.x) is API
stability.

Be sure to check the lastest CVS News file
(http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cppunit/cppunit/NEWS)
content for compatibility break and deprecation that occured since 1.9.8.

Baptiste.

----- Original Message -----
From: "Luis Joaquim" <ljo...@cr...>
To: <cpp...@li...>
Sent: Tuesday, August 20, 2002 1:45 PM
Subject: [Cppunit-devel] Cppunit 1.9.8 Stable?


> Hello,
>
>  I had a look at CppUnit Version 1.9.8, and it has some enhancements
>  that I liked to use, such as, XMLDocument, XmlOutputterHook, and
>  others.
>
>  Is it stable so I can adopt it at my company ?
>
>  Thanks,
>
>  Luis Joaquim
>
>
> Critical Software, SA
> EN1/IC2, Km 185,6, Banhos Secos, Santa Clara
> 3040-032 Coimbra
> Tel: +351.239.801300, Fax: +351.239.801319
> http://www.criticalsoftware.com

Re: [Cppunit-devel] need manual on cppunit

[Baptiste L. <gai...@fr...>]

Such a document does not exist. What come the closest to it is the task
oriented documentation. You can get it from:
http://cppunit.sourceforge.net/snapshot/cppunit-docs-1.9.8.tar.gz

Look up the 'module' section.

Baptiste.

----- Original Message -----
From: "Kalagani Ramana Babu - CTD, Chennai." <ram...@ct...>
To: <cpp...@li...>
Sent: Wednesday, August 21, 2002 5:18 PM
Subject: [Cppunit-devel] need manual on cppunit


> Hi,
>      I am Ramana Babu. Can u please send me the features of CPP unit and
> alos the information how to use this cppunit to test my application.Thanks
> in advance
> Ramana Babu

[Cppunit-devel] CppUnit and Extension DLL vs. Regular DLL

[Steffen H. <ste...@we...>]

Hi,

I want to run the TestRunner Dialog (controlled in testrunner.dll) out of a ActiveX control (OCX). The problem is that testrunner.dll is built as an MFC Extension DLL.
It was generated by Visual C++ wizard where this problem seems to be known because in TestRunnerApp.cpp following comment is also describing my problem:

        // Insert this DLL into the resource chain
        // NOTE: If this Extension DLL is being implicitly linked to by
        //  an MFC Regular DLL (such as an ActiveX Control)
        //  instead of an MFC application, then you will want to
        //  remove this line from DllMain and put it in a separate
        //  function exported from this Extension DLL.  The Regular DLL
        //  that uses this Extension DLL should then explicitly call that
        //  function to initialize this Extension DLL.  Otherwise,
        //  the CDynLinkLibrary object will not be attached to the
        //  Regular DLL's resource chain, and serious problems will
        //  result.

I followed these instructions but nothing changed.

What really is the advantage of using Extension DLL, I don`t know?
The only point I can image is to no longer need to use macro AFX_MANAGE_STATE.

First of all it chrashes because no resources of the testrunner.dll are found.

Then I add "AfxSetResourceHandle(::GetModuleHandle("testrunner.dll"))" and the resources are found but then it crashes while creating the dialog because AfxGetInstanceHandle() returns NULL.

Does anyone of you has an idea to fix this?

The only one solution for me at the moment is to build an additional regular dll using the same code. Such a dll is running out of an OCX without problems.

What do you think about adding this DLL to CppUnit?

Best regards
Steffen
______________________________________________________________________________
Wieviele E-Mail-Adressen haben Sie? Eine, funf oder gar zehn? Verwalten
Sie doch einfach alle unter: http://freemail.web.de/?mc=021120

[Cppunit-devel] need manual on cppunit

[Kalagani R. B. - C. Chennai. <ram...@ct...>]

Hi,
     I am Ramana Babu. Can u please send me the features of CPP unit and
alos the information how to use this cppunit to test my application.Thanks
in advance
Ramana Babu

[Cppunit-devel] Cppunit 1.9.8 Stable?

[Luis J. <ljo...@cr...>]

Hello,

 I had a look at CppUnit Version 1.9.8, and it has some enhancements
 that I liked to use, such as, XMLDocument, XmlOutputterHook, and
 others.

 Is it stable so I can adopt it at my company ?

 Thanks,

 Luis Joaquim
 
  
Critical Software, SA
EN1/IC2, Km 185,6, Banhos Secos, Santa Clara
3040-032 Coimbra
Tel: +351.239.801300, Fax: +351.239.801319
http://www.criticalsoftware.com

Re: [Cppunit-devel] CppUnit documentation

[Luis J. <ljo...@cr...>]

Hello,

yes. Doxygen (im my opinion)

http://www.stack.nl/~dimitri/doxygen/


Luis Joaquim


Thursday, August 15, 2002, 9:53:29 AM, you wrote:

DC> Hi,
 
DC> I was wondering how the documentation for CppUnit was generated. I work
DC> primarily with java, and so therefore am well acquainted with javadoc.
DC> Is there a good equivalent to javadoc available for C++?
 
DC> Many thanks,
DC> Daniel Century


---
Luis Joaquim
Critical Software, SA
EN1/IC2, Km 185,6, Banhos Secos, Santa Clara
3040-032 Coimbra
Tel: +351.239.801300, Fax: +351.239.801319
http://www.criticalsoftware.com
ljo...@cr...

[Cppunit-devel] CppUnit documentation

[Daniel C. <dan...@tr...>]

Hi,
=20
I was wondering how the documentation for CppUnit was generated. I work
primarily with java, and so therefore am well acquainted with javadoc.
Is there a good equivalent to javadoc available for C++?
=20
Many thanks,
Daniel Century

[Cppunit-devel] URGENT: Solaris/Sparc Compilation problems

[Darragh S. <Dar...@Su...>]

Hi,
	I have been trying to compiling CppUnit on Solaris/Sparc with the native
compiler SparcWorks/Forte 6 Update 1 with the Standard Template Library
that comes with the compiler.
Do I need STLport to compile CppUnit?

I was running a make and I got the following error:

/opt/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I. -I../../config
-I../../include -I../../include -I.
-I/scde/webtop/re/SRX643/unxsols3.pro/inc/stl
-I/scde/webtop/re/SRX643/unxsols3.pro/inc/external
-I/scde/webtop/re/SRX643/unxsols3.pro/inc
-I/scde/webtop/re/SRX643/src/solenv/unxsols3/inc -I/opt/SUNWspro/include
-I/scde/webtop/re/SRX643/src/solenv/inc
-I/scde/webtop/re/SRX643/unxsols3.pro/inc/stl
-I/scde/webtop/re/SRX643/src/solenv/inc/Xp31
-I/scde/webtop/re/SRX643/src/res -I.
-I/scde/webtop/re/SRX643/unxsols3.pro/inc/stl
-I/scde/webtop/re/SRX643/unxsols3.pro/inc/external
-I/scde/webtop/re/SRX643/unxsols3.pro/inc
-I/scde/webtop/re/SRX643/src/solenv/unxsols3/inc -I/opt/SUNWspro/include
-I/scde/webtop/re/SRX643/src/solenv/inc
-I/scde/webtop/re/SRX643/unxsols3.pro/inc/stl
-I/scde/webtop/re/SRX643/src/solenv/inc/Xp31
-I/scde/webtop/re/SRX643/src/res -I../../include/cppunit
-I/scde/webtop/re/SRX643/inc/stl/stl/wrappers
-I/scde/webtop/re/SRX643/inc/stl/stl -c TestFactoryRegistry.cpp  -KPIC -DPIC
"TestFactoryRegistry.cpp", line 43: Error: Could not find a match for
_STL::map<_STL::basic_string<char, _STL::char_traits<char>,
_STL::allocator<char>>, CppUnit::TestFactoryRegistry*,
_STL::less<_STL::basic_string<char, _STL::char_traits<char>,
_STL::allocator<char>>>, _STL::allocator<_STL::pair<const
_STL::basic_string<char, _STL::char_traits<char>,
_STL::allocator<char>>,
CppUnit::TestFactoryRegistry*>>>::insert(_STL::pair<_STL::basic_string<char, 

_STL::char_traits<char>, _STL::allocator<char>>,
CppUnit::TestFactoryRegistry*>).
1 Error(s) detected.
*** Error code 1
make: Fatal error: Command failed for target `TestFactoryRegistry.lo'

Here are the CXXFLAGS I used:
   echo $CXXFLAGS
-I. -I/scde/webtop/re/SRX643/unxsols3.pro/inc/stl
-I/scde/webtop/re/SRX643/unxsols3.pro/inc/external
-I/scde/webtop/re/SRX643/unxsols3.pro/inc
-I/scde/webtop/re/SRX643/src/solenv/unxsols3/inc -I/opt/SUNWspro/include
-I/scde/webtop/re/SRX643/src/solenv/inc
-I/scde/webtop/re/SRX643/unxsols3.pro/inc/stl
-I/scde/webtop/re/SRX643/src/solenv/inc/Xp31
-I/scde/webtop/re/SRX643/src/res -I../../include/cppunit
-I/scde/webtop/re/SRX643/inc/stl/stl/wrappers
-I/scde/webtop/re/SRX643/inc/stl/stl

Does anybody know about this error?
Any help you be great!
Please send all replies directly to me as I am not on the mailing list.
Thanks

-- 
_______________________
Darragh Sherwin
Email: Dar...@Su...
Phone: x19788/+353-1-8199788

"To alcohol, the cause of, and solution to, all of life's problems"
					Homer Simpson

RE: [Cppunit-devel] Mock C++

[Philippe F. <P....@OB...>]

> Here is a example of a mock object in C++. Notes that it is slighty
> different than the java implementation. Compare this to the implementation
> of MockTestCase in cppunit test suite and you'll see how much easier it
> is...
> 
> class MockProjectBuilder : public AbstractProjectBuilder
>                          , public XtlUt::MockObject
> {
> public:
>   /*! Constructs a MockProjectBuilder object.
>    */
>   MockProjectBuilder( const std::string &name );
> 
>   /// Destructor.
>   virtual ~MockProjectBuilder();
> 
>   virtual void beginGroup( const std::string &groupName );
>   virtual void endGroup();
> 
>   virtual void addSourceFile( const std::string &relativePath );
> 
>   void setExpectNoGroup();
>   void addExpectedGroupName( const std::string &expectedGroupName );
>   void addExpectedEndGroup();
> 
>   void setExpectNoSourceFile();
>   void addExpectedSourceFile( const std::string 
> &expectedRelativePath );
> 
>   void setExpectNoMethodCalls();
> 
> private:
>   /// Prevents the use of the copy constructor.
>   MockProjectBuilder( const MockProjectBuilder &other );
> 
>   /// Prevents the use of the copy operator.
>   void operator =( const MockProjectBuilder &other );
> 
> private:
>   XtlUt::ExpectationCounter _endGroupCalls;
>   XtlUt::ExpectationStringSequence _addSourceFileValues;
>   XtlUt::ExpectationStringSequence _addGroupNames;
>   XtlUt::ExpectationStringSequence _methodCalls;
> };

Your example is not exactly crystal clear to me. Tell me if I understood
correctly:

1. class ProjectBuilder has methods beginGroup(), endGroup() and
addSouceFile()

2. to record the call being made, you use the addActual() function

3. to record the arguments of the functions, you use addActual() on
ExpectationStringSequence that are specific to a function.

4. the setExpect stuff is here to match expect vs actual

5. you do not handle return values.

If I understood right, your framework does not look very generic to me, and
requires many manual calls. I think we can do better.

To record the called made to a function, we could add a simple macro just
after every function calls. Compilers usually have a __FUNCTION__ that
contains the name of the function, so this could be automatic. It would
record the function being called. Using a dictionnary behind that, you would
be able to store and retrieve specific information about each function call.

If we assume all objects can be compared using their string representation,
we can store the expected and actual arguments of every function.

The only thing I haven't been able to figure out yet is how to handle return
values.

I'll read some C++ books and see if I can find a solution.

	regards,

	Philippe

RE: [Cppunit-devel] Mock C++

[Philippe F. <P....@OB...>]

> I'm unfamiliar with Mock objects.. do you mind giving a better explanation
than the one in easymock.org? 
> For some reason, the author chose to use the word Mock to describe Mock
objects.  A bit confusing for the 
> layman. 

A mock object is an object that mocks (simulates) a legacy object. You can
manipulate it like the object it mocks. It has the additional properties
that when its methods are invoked it does nothing except registering the
call and returning a defined value. 

To use it in a test, you pass the mock object to a function you want to
test. The function is supposed to perform certain calls on the mock object.
When the function returns, you check in your mock objects that the calls are
the one you were expecting.

Imagine you have a methods that takes a visitor and you want to check if it
passes the correct info to the visitor. You would have something like:

class Tree :
{
	// [...]
	void visitTree( Visitor * it );
};

class Visitor
{
	// [...]
	virtual void visitFoo( Foo * foo);
	virtual void visitBar( Bar * bar);
}

In your test, you want to check that visitor is called correctely. The way
to do that is to have a mock for the visitor:

class MockVisitor : Visitor
{
	// [...]
	void visitFoo( Foo * foo ) {
		// register that visitFoo was called with argument foo
	}

	void visitBar( Bar * bar ) {
		// register that visitBar was called with argument bar
	}
};

TestTree::testVisitTree()
{
	Tree tree;
	tree.load( "Foo1Foo2Bar1" );	// prepare a tree with two Foo1,
Foo2 and Bar1

	mock = new MockVisitor();
	tree.visitTree( mock );

	// check that first call to mock was visitFoo( foo1 )
	// check that second call to mock was visitFoo( foo2 )	
	// check that third call to mock was visitBar( bar1 )	
}

It is far easier to implement that in Java or Python for many reasons.

In C++, using a mock requires that all function to be called are virtual, so
that they can be overridden in the mock.

In this example, the mock does not return anything, but if the function is
expected to return a value, the value must be setup before passing the mock.


So the requirements for a mock object in C++ are:
- an object that can be called like another object it mimicks. I only see
inheritance as a way to do that byt I am not very experienced with
templates.

- each call to the object must be intercepted: each function to be called
must be coded manually (this is not the case in python, you can
automatically intercept calls). So you must provide an easy interface to
notify that a call was made to a certain function.

- every argument to a function called must be stored and compared to what
was expected. I don't know if templates can cleverly handles this one. It
sounds tricky to me to store and compare objects you do not know beforehand.
But as I said, I am in no way a template guy. Using a string representation
of the objects to store them and compare them sounds to me like a simple and
implementable solution.

- store the return value so that it can be returned when the function call
is make. That sounds really tricky to me. String serialisation can not
handle that. I don't think simple template usage can. Advanced template
certainly can however. An idea is emerging on how to do that.


What is sure is that implementing this is C++ will be a lot more complicated
than in other languages.

	regards,

	Philippe

Re: [Cppunit-devel] Mock C++

[Baptiste L. <gai...@fr...>]

I actually implemented this as part of a library that come on top of CppUnit
(but not yet released). The library implemented advanced assertion (equality
with automatic conversion, collection equality...). The mock part of the
library is build upon those assertion which make things much easier.

Here is a example of a mock object in C++. Notes that it is slighty
different than the java implementation. Compare this to the implementation
of MockTestCase in cppunit test suite and you'll see how much easier it
is...

class MockProjectBuilder : public AbstractProjectBuilder
                         , public XtlUt::MockObject
{
public:
  /*! Constructs a MockProjectBuilder object.
   */
  MockProjectBuilder( const std::string &name );

  /// Destructor.
  virtual ~MockProjectBuilder();

  virtual void beginGroup( const std::string &groupName );
  virtual void endGroup();

  virtual void addSourceFile( const std::string &relativePath );

  void setExpectNoGroup();
  void addExpectedGroupName( const std::string &expectedGroupName );
  void addExpectedEndGroup();

  void setExpectNoSourceFile();
  void addExpectedSourceFile( const std::string &expectedRelativePath );

  void setExpectNoMethodCalls();

private:
  /// Prevents the use of the copy constructor.
  MockProjectBuilder( const MockProjectBuilder &other );

  /// Prevents the use of the copy operator.
  void operator =( const MockProjectBuilder &other );

private:
  XtlUt::ExpectationCounter _endGroupCalls;
  XtlUt::ExpectationStringSequence _addSourceFileValues;
  XtlUt::ExpectationStringSequence _addGroupNames;
  XtlUt::ExpectationStringSequence _methodCalls;
};


MockProjectBuilder::MockProjectBuilder( const std::string &name )
    : MockObject( name )
    , _addGroupNames( "beginGroup() parameter" )
    , _endGroupCalls( "endGroup() calls" )
    , _addSourceFileValues( "addSourceFile() parameter" )
    , _methodCalls( "sequence of method calls" )
{
  add( _addGroupNames );
  add( _endGroupCalls );
  add( _addSourceFileValues );
  add( _methodCalls );
}


MockProjectBuilder::~MockProjectBuilder()
{
}


void
MockProjectBuilder::beginGroup( const std::string &groupName )
{
  _methodCalls.addActual( "beginGroup()" );
  _addGroupNames.addActual( groupName );
}


void
MockProjectBuilder::endGroup()
{
  _methodCalls.addActual( "endGroup()" );
  _endGroupCalls.inc();
}


void
MockProjectBuilder::addSourceFile( const std::string &relativePath )
{
  _methodCalls.addActual( "addSourceFile()" );
  _addSourceFileValues.addActual( relativePath );
}


void
MockProjectBuilder::setExpectNoGroup()
{
  _addGroupNames.setExpectNothing();
  _endGroupCalls.setExpectNothing();
}


void
MockProjectBuilder::addExpectedGroupName( const std::string
&expectedGroupName )
{
  _addGroupNames.addExpected( expectedGroupName );
  _methodCalls.addExpected( "beginGroup()" );
  _endGroupCalls.setExpected( _addGroupNames.expectedValueCount() );
}


void
MockProjectBuilder::addExpectedEndGroup()
{
  _methodCalls.addExpected( "endGroup()" );
}


void
MockProjectBuilder::setExpectNoSourceFile()
{
  _addSourceFileValues.setExpectNothing();
}


void
MockProjectBuilder::addExpectedSourceFile( const std::string
&expectedRelativePath )
{
  _addSourceFileValues.addExpected( expectedRelativePath );
  _methodCalls.addExpected( "addSourceFile()" );
}


void
MockProjectBuilder::setExpectNoMethodCalls()
{
  _methodCalls.setExpectNothing();
}


Baptiste.


----- Original Message -----
From: "Philippe FREMY" <P....@OB...>
To: <cpp...@li...>
Sent: Tuesday, August 13, 2002 11:15 AM
Subject: [Cppunit-devel] Mock C++


>
> Hi,
>
> Have you guys thought about doing Mock objects for C++ ? It comes
naturally
> after Junit.
>
> More info about mocks:
>
> http://www.easymock.org/readme.html
> http://www.mockobjects.com
>
> We probably can not reach the versatility of Java here, but we can sure do
> something.
>
> regards,
>
> Philippe
---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/

RE: [Cppunit-devel] Mock C++

[lacall <la...@mi...>]

In case it helps, there seem to be 2-3 articles on this here:
http://www.junit.org/news/article/index.htm
<http://www.junit.org/news/article/index.htm> 
...if you search the page for "mock."
 
Luke 
 -----Original Message-----
From: Moran Ben-David [mailto:mbe...@ii...]
Sent: Tuesday, August 13, 2002 9:26 AM
To: 'Philippe FREMY'; cpp...@li...
Subject: RE: [Cppunit-devel] Mock C++



I'm unfamiliar with Mock objects.. do you mind giving a better explanation
than the one in easymock.org? 

For some reason, the author chose to use the word Mock to describe Mock
objects.  A bit confusing for the layman. 

thanks, 
moran 

-----Original Message----- 
From: Philippe FREMY [ mailto:P....@OB...
<mailto:P....@OB...> ] 
Sent: Tuesday, August 13, 2002 5:15 AM 
To: cpp...@li... 
Subject: [Cppunit-devel] Mock C++ 



        Hi, 

Have you guys thought about doing Mock objects for C++ ? It comes naturally 
after Junit. 

More info about mocks: 

http://www.easymock.org/readme.html <http://www.easymock.org/readme.html>  
http://www.mockobjects.com <http://www.mockobjects.com>  

We probably can not reach the versatility of Java here, but we can sure do 
something. 

        regards, 

        Philippe 



------------------------------------------------------- 
This sf.net email is sponsored by: Dice - The leading online job board 
for high-tech professionals. Search and apply for tech jobs today! 
http://seeker.dice.com/seeker.epl?rel_code=31
<http://seeker.dice.com/seeker.epl?rel_code=31>  
_______________________________________________ 
Cppunit-devel mailing list 
Cpp...@li... 
https://lists.sourceforge.net/lists/listinfo/cppunit-devel
<https://lists.sourceforge.net/lists/listinfo/cppunit-devel>  

[Cppunit-devel] RE: Mock C++

[King D. <Ki...@tc...>]

> Have you guys thought about doing Mock objects for C++ ? It comes
naturally
> after Junit.

> We probably can not reach the versatility of Java here, but we can sure do
> something.

I've thought about it a lot and done some work in that direction and also
got input from someone else that started on it (and didn't get any farther
than me).

Unfortunately, there are so many things about Javaa that make it so much
easier than with C++. Chief among those is reflection. With mock objects in
Java just by having a member of the instance be a subclass of Verifiable it
will get verified. There is no easy way to do that in C++. You end up having
to do things like with CppUnit where you use complex macros to add things to
be verified.

I also looked at using something like OpenC++ which is sort of a
preprocessor for C++ which can give you compile time reflection.

I'd be happy to share what I started and what other examples I was given,
but you could probably get that far yourself pretty easily.

-- 
 Dale King

RE: [Cppunit-devel] Mock C++

[Moran Ben-D. <mbe...@ii...>]

I'm unfamiliar with Mock objects.. do you mind giving a better explanation
than the one in easymock.org?

For some reason, the author chose to use the word Mock to describe Mock
objects.  A bit confusing for the layman.

thanks,
moran

-----Original Message-----
From: Philippe FREMY [mailto:P....@OB...]
Sent: Tuesday, August 13, 2002 5:15 AM
To: cpp...@li...
Subject: [Cppunit-devel] Mock C++



	Hi,

Have you guys thought about doing Mock objects for C++ ? It comes naturally
after Junit.

More info about mocks:

http://www.easymock.org/readme.html
http://www.mockobjects.com

We probably can not reach the versatility of Java here, but we can sure do
something.

	regards,

	Philippe



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

[Cppunit-devel] Mock C++

[Philippe F. <P....@OB...>]

	Hi,

Have you guys thought about doing Mock objects for C++ ? It comes naturally
after Junit.

More info about mocks:

http://www.easymock.org/readme.html
http://www.mockobjects.com

We probably can not reach the versatility of Java here, but we can sure do
something.

	regards,

	Philippe

Re: [Cppunit-devel] Question about TestFixture

[Luis J. <ljo...@cr...>]

Hello,

 I believe you can do that, by calling those methods in the setUp()
 method.

 Luis Joaquim

Friday, August 9, 2002, 1:53:59 PM, you wrote:

BM> I have made a test fixture and I can call it by using a test runner. That's
BM> ok.
BM> But now my problem is that I need to call some functions on my instance of
BM> my test object before I can really start to use it.
BM> How to do this?
BM> From what I understand this is not possible using the helper macro's. Is
BM> there another way?

BM> ----------------------------------------------------------------------------

BM> Marc Bogaerts - Software Engineer
BM> Phone : +32 (0)2 370.36.37 - e-mail : mb...@fa... 
BM> ----------------------------------------------------------------------------

BM> S.A. FABRICOM N.V. 
BM> Rue Gatti de Gamond, 254 - B-1180 Bruxelles - Belgium 
BM> General Phone : +32 (0)2 370.33.35 - Fax : +32 (0)2 370.32.22 
BM> ----------------------------------------------------------------------------


BM> The information contained in this e-mail is intended only for the person or
BM> entity to which it is addressed and may contain confidential and / or
BM> privileged material. If you are not the intended recipient of this e-mail,
BM> the use of this information or any disclosure, copying or distribution is
BM> prohibited and may be unlawful. 

BM> If you received this in error, please contact the sender and delete the
BM> material from any computer.



BM> This electronic transmission is intended exclusively for the person to 
BM> whom it is addressed and may contain privileged and confidential material.
BM> Any disclosure, copying, distribution or other action based upon 
BM> the information by persons other than the intended recipient
BM> is prohibited. If you receive this message in error, please contact the 
BM> sender and delete the material. 
BM> Our company does not warrant a proper and complete transmission of this
BM> information, nor does it accept liability for any delays.



----------------------------------------------------------------------------
------------
Critical Software has changed address and phones -
please check new contacts below
----------------------------------------------------------------------------
------------
---
Luis Joaquim
Critical Software, SA
EN1/IC2, Km 185,6, Banhos Secos, Santa Clara
3040-032 Coimbra
Tel: +351.239.801300, Fax: +351.239.801319
http://www.criticalsoftware.com
ljo...@cr...

[Cppunit-devel] Question about TestFixture

[Bogaerts M. <MB...@fa...>]

I have made a test fixture and I can call it by using a test runner. That's
ok.
But now my problem is that I need to call some functions on my instance of
my test object before I can really start to use it.
How to do this?
From what I understand this is not possible using the helper macro's. Is
there another way?

----------------------------------------------------------------------------

Marc Bogaerts - Software Engineer
Phone : +32 (0)2 370.36.37 - e-mail : mb...@fa... 
----------------------------------------------------------------------------

S.A. FABRICOM N.V. 
Rue Gatti de Gamond, 254 - B-1180 Bruxelles - Belgium 
General Phone : +32 (0)2 370.33.35 - Fax : +32 (0)2 370.32.22 
----------------------------------------------------------------------------


The information contained in this e-mail is intended only for the person or
entity to which it is addressed and may contain confidential and / or
privileged material. If you are not the intended recipient of this e-mail,
the use of this information or any disclosure, copying or distribution is
prohibited and may be unlawful. 

If you received this in error, please contact the sender and delete the
material from any computer.



This electronic transmission is intended exclusively for the person to 
whom it is addressed and may contain privileged and confidential material.
Any disclosure, copying, distribution or other action based upon 
the information by persons other than the intended recipient
is prohibited. If you receive this message in error, please contact the 
sender and delete the material. 
Our company does not warrant a proper and complete transmission of this
information, nor does it accept liability for any delays.

[Cppunit-devel] Thanks for this port to CPP!!

[Harris, J. J <JJH...@un...>]

Hi,
    I'm a programmer just discovering XProgramming, Refactoring etc..  I'm
in a situation where there is lack of knowledge in source code for one of
our large systems.  People are afraid to make changes, progress goes slow.
In reading about XP I found the XP web site that pointed me to your CPP port
of JUnit.  I just got the examples compiled and running.  My next challenge
will be to apply it to one of our classes for testing, and then to
demonstrate it to other programmers in a way that convinces them to use it.
Do you know if there are any other examples of the test tool being used to
test classes of different names?  I feel using the CppUnit classes to
demonstrate the CppUnit testing makes things slower to pick up because one
is dealing with names that are so similar.  Anyhow, maybe its me, its late,
and I probably have to look at it a bit more.  I'm just glad to have found
this right now, and have it compiled and working!!
 
Thanks for making this kind of testing possible.  Now I hope to apply its
use to bring clarity, understanding, and better code to reality here, one
step at a time!!!
 
 
Thanks!
 
John
email: jjh...@un... <mailto:jjh...@un...> 

Re[4]: [Cppunit-devel] URGENT: more information to be logged

[Luis J. <ljo...@cr...>]

Hello,

  That is a good solution.

  I solved my problem, by adding members in the Test (like name
  exists), and in the CPPUNIT_TEST() macro for adding the test to the
  suite, I added more arguments.

  My problem right now is the difficulty that will arrise when I want
  to upgrade Cppunit with new releases.

  Luis Joaquim
  

Friday, August 2, 2002, 3:11:38 PM, you wrote:

MA> Hi.

MA> Currently it is very simple:

MA> - you can write test methods that take additional input as parameters
MA> - this input is read from an in-file (XML)

MA> I also suggested a more elaborate version of this approach (see
MA> devel-mailing list archive):

MA> - Introduce the notion of a TestContext in the Test interface
MA> - test methods would then use the TestContext to make use of
MA> input-parameters (see above)
MA> - TestOutputter would also be able to access this TestContext; this fact
MA> could be used to provide
MA>   the additional information that you want to be outputted. This information
MA> could of course be
MA>   included in the XML file that also contains the different
MA> parameterizations for the tests

MA> The TestContext class would be designed as a key/value-container. There
MA> would have to be a new/specialized Outputter that "knows" the content of the
MA> TestContext (the keys). Or the Outputter could just provide a basic support
MA> for outputting the contents of TestContext (iterating over all key/value
MA> pairs).

MA> But there hasn't been much interest in this concept, so we just developed
MA> the easy version yet...

MA> Regards

MA> Armin (bored)

>> -----Original Message-----
>> From: Luis Joaquim [mailto:ljo...@cr...]
>> Sent: Freitag, 2. August 2002 15:58
>> To: Michel Armin
>> Subject: Re[2]: [Cppunit-devel] URGENT: more information to be logged
>> 
>> 
>> Viva,
>> 
>> Can you give me an idea of what that approach is ?
>> 
>> Thanks,
>> 
>> Luis Joaquim
>> 
>> Friday, August 2, 2002, 2:46:02 PM, you wrote:
>> 
>> MA> Maybe the "parameterized tests" approach we just 
>> developed may help you
>> MA> here.
>> MA> But currently this new feature isn't available in the CVS yet.
>> 
>> MA> Regards,
>> 
>> MA> bored
>> 
>> >> -----Original Message-----
>> >> From: Luis Joaquim [mailto:ljo...@cr...]
>> >> Sent: Montag, 29. Juli 2002 17:03
>> >> To: cpp...@li...
>> >> Subject: [Cppunit-devel] URGENT: more information to be logged
>> >> Importance: High
>> >> 
>> >> 
>> >> Hello,
>> >> 
>> >>   I need to report more information about the tests, like a brief
>> >>   description, the inputs and outputs.
>> >> 
>> >>   The programmer will write this fields (strings).
>> >> 
>> >>   I have thought on the implementation and it seems I have 
>> to change a
>> >>   lot of files, and would my very hard future upgrades.
>> >> 
>> >>   Does anyone know a better solution?
>> >> 
>> >>   Does anyone have the some problem?
>> >> 
>> >>   Don't you think it would be a nice feature?
>> >> 
>> >>   Thanks in advance,
>> >> 
>> >>   Luis Joaquim
>> >> 
>> >> -- 
>> >> Luis Joaquim
>> >> Critical Software, SA
>> >> EN1/IC2, Km 185,6, Banhos Secos, Santa Clara
>> >> 3040-032 Coimbra
>> >> Tel: +351.239.801300, Fax: +351.239.801319
>> >> http://www.criticalsoftware.com
>> >> 
>> >> 
>> >> 
>> >> -------------------------------------------------------
>> >> This sf.net email is sponsored by: Dice - The leading 
>> online job board
>> >> for high-tech professionals. Search and apply for tech jobs today!
>> >> http://seeker.dice.com/seeker.epl?rel_code=31
>> >> _______________________________________________
>> >> Cppunit-devel mailing list
>> >> Cpp...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>> >> 
>> 
>> 
>> MA> -------------------------------------------------------
>> MA> This sf.net email is sponsored by:ThinkGeek
>> MA> Welcome to geek heaven.
>> MA> http://thinkgeek.com/sf
>> MA> _______________________________________________
>> MA> Cppunit-devel mailing list
>> MA> Cpp...@li...
>> MA> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>> 
>> 
>> --------------------------------------------------------------
>> --------------
>> ------------
>> Critical Software has changed address and phones -
>> please check new contacts below
>> --------------------------------------------------------------
>> --------------
>> ------------
>> ---
>> Luis Joaquim
>> Critical Software, SA
>> EN1/IC2, Km 185,6, Banhos Secos, Santa Clara
>> 3040-032 Coimbra
>> Tel: +351.239.801300, Fax: +351.239.801319
>> http://www.criticalsoftware.com
>> ljo...@cr...
>> 


----------------------------------------------------------------------------
------------
Critical Software has changed address and phones -
please check new contacts below
----------------------------------------------------------------------------
------------
---
Luis Joaquim
Critical Software, SA
EN1/IC2, Km 185,6, Banhos Secos, Santa Clara
3040-032 Coimbra
Tel: +351.239.801300, Fax: +351.239.801319
http://www.criticalsoftware.com
ljo...@cr...

RE: Re[2]: [Cppunit-devel] URGENT: more information to be logged

[Michel A. <Arm...@si...>]

Hi.

Currently it is very simple:

- you can write test methods that take additional input as parameters
- this input is read from an in-file (XML)

I also suggested a more elaborate version of this approach (see
devel-mailing list archive):

- Introduce the notion of a TestContext in the Test interface
- test methods would then use the TestContext to make use of
input-parameters (see above)
- TestOutputter would also be able to access this TestContext; this fact
could be used to provide
  the additional information that you want to be outputted. This information
could of course be
  included in the XML file that also contains the different
parameterizations for the tests

The TestContext class would be designed as a key/value-container. There
would have to be a new/specialized Outputter that "knows" the content of the
TestContext (the keys). Or the Outputter could just provide a basic support
for outputting the contents of TestContext (iterating over all key/value
pairs).

But there hasn't been much interest in this concept, so we just developed
the easy version yet...

Regards

Armin (bored)

> -----Original Message-----
> From: Luis Joaquim [mailto:ljo...@cr...]
> Sent: Freitag, 2. August 2002 15:58
> To: Michel Armin
> Subject: Re[2]: [Cppunit-devel] URGENT: more information to be logged
> 
> 
> Viva,
> 
> Can you give me an idea of what that approach is ?
> 
> Thanks,
> 
> Luis Joaquim
> 
> Friday, August 2, 2002, 2:46:02 PM, you wrote:
> 
> MA> Maybe the "parameterized tests" approach we just 
> developed may help you
> MA> here.
> MA> But currently this new feature isn't available in the CVS yet.
> 
> MA> Regards,
> 
> MA> bored
> 
> >> -----Original Message-----
> >> From: Luis Joaquim [mailto:ljo...@cr...]
> >> Sent: Montag, 29. Juli 2002 17:03
> >> To: cpp...@li...
> >> Subject: [Cppunit-devel] URGENT: more information to be logged
> >> Importance: High
> >> 
> >> 
> >> Hello,
> >> 
> >>   I need to report more information about the tests, like a brief
> >>   description, the inputs and outputs.
> >> 
> >>   The programmer will write this fields (strings).
> >> 
> >>   I have thought on the implementation and it seems I have 
> to change a
> >>   lot of files, and would my very hard future upgrades.
> >> 
> >>   Does anyone know a better solution?
> >> 
> >>   Does anyone have the some problem?
> >> 
> >>   Don't you think it would be a nice feature?
> >> 
> >>   Thanks in advance,
> >> 
> >>   Luis Joaquim
> >> 
> >> -- 
> >> Luis Joaquim
> >> Critical Software, SA
> >> EN1/IC2, Km 185,6, Banhos Secos, Santa Clara
> >> 3040-032 Coimbra
> >> Tel: +351.239.801300, Fax: +351.239.801319
> >> http://www.criticalsoftware.com
> >> 
> >> 
> >> 
> >> -------------------------------------------------------
> >> This sf.net email is sponsored by: Dice - The leading 
> online job board
> >> for high-tech professionals. Search and apply for tech jobs today!
> >> http://seeker.dice.com/seeker.epl?rel_code=31
> >> _______________________________________________
> >> Cppunit-devel mailing list
> >> Cpp...@li...
> >> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> >> 
> 
> 
> MA> -------------------------------------------------------
> MA> This sf.net email is sponsored by:ThinkGeek
> MA> Welcome to geek heaven.
> MA> http://thinkgeek.com/sf
> MA> _______________________________________________
> MA> Cppunit-devel mailing list
> MA> Cpp...@li...
> MA> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 
> 
> --------------------------------------------------------------
> --------------
> ------------
> Critical Software has changed address and phones -
> please check new contacts below
> --------------------------------------------------------------
> --------------
> ------------
> ---
> Luis Joaquim
> Critical Software, SA
> EN1/IC2, Km 185,6, Banhos Secos, Santa Clara
> 3040-032 Coimbra
> Tel: +351.239.801300, Fax: +351.239.801319
> http://www.criticalsoftware.com
> ljo...@cr...
>