Hi,

AssertEquals always gives an Access violation error for some reason. First some background info is needed....

I first write some of my tests using AssertTrue as follows:
  AssertTrue('Failed on 2', posClean = lNode1.ObjectState);

This just raise the exception when they didn't match. I preferred to have the style expected but got message. So I started change those tests to the following:

  AssertEquals('Failed on 5', ObjectStateToString(posClean),
    ObjectStateToString(lList.ObjectState));

This worked fine, but after doing this for a while I realized I am typing my life away with all those ObjectStateToString() calls. Then I thought, why don't I create a new AssertEquals method for my projects that take TPerObjectState as parameters. So I created this in my custom test case class.

{ defined under Public }
procedure TM2TestCase.AssertEquals(const pMessage: string; pExpected,
  pActual: TPerObjectState);
begin
  AssertEquals(pMessage,
    ObjectStateToString(pExpected),
    ObjectStateToString(pActual));
end;

BTW: TPerObjectState is define as follows...

  TPerObjectState = (
                      posEmpty,
                      posPK,
                      posCreate,
                      posUpdate,
                      posDelete,
                      posDeleted,
                      posClean
                     ) ;

Now changing my test to the following, which is much easier to type and read:

  AssertEquals('Failed on 1', posEmpty, lLang.ObjectState);

Finally, getting back to the problem. Using this new AssertEquals always gives me a Access violation error. I know there is a AssertEquals that uses TClass, could that interfere with this? I even tried changing my new AssertEquals to use a different name AssertEqualsObjState(), but that didn't help either.

What could be causing the problem?

Regards,
- Graeme -

Oh, I forgot to mention. If the ObjectStates match, the test passes fine, and doesn't give an access violation.

While creating the new AssertEquals method, I purposefully created a failure with then gives the access violation, instead to the comparison message I expected:
"Failing on 1: Expected <posClean> but got <posEmpty>"

Regards,
- Graeme -

Try creating a back trace, maybe that gives some insight.

Vincent

Here is the backtrace. I removed all other Assert tests, so only the one that causes the problem is executed.

What is strange though, is that I created a new test that only creates the object and then tests the ObjectState. It it works, but all the other actual tests don't. I hate such problems! :-)

Graeme.

-------------- Start ---------------
[New Thread -1216787536 (LWP 20619)]
[Switching to Thread -1213515552 (LWP 20607)]

Breakpoint 1, 0x0805f036 in fpc_raiseexception ()
(gdb) bt
#0 0x0805f036 in fpc_raiseexception ()
#1 0x082189d9 in FPCUNIT_TASSERT_$__FAIL$ANSISTRING () #2 0xb7f04ac0 in ?? ()
#3 0xb7a69200 in ?? ()
#4 0x082189ff in FPCUNIT_TASSERT_$__ASSERTTRUE$ANSISTRING$BOOLEAN () #5 0xb7f04ac0 in ?? ()
#6 0x08218b45 in
FPCUNIT_TASSERT_$__ASSERTEQUALS$ANSISTRING$ANSISTRING$ANSISTRING () #7 0x080a0202 in TNODEDATATEST__ASSERTEQUALS (PMESSAGE=0x8350cf0, PEXPECTED=POSDELETED, PACTUAL=POSCLEAN, this=0xb7a77a68) at NodeData_test.pas:89
#8 0x080a1cb7 in TNODEDATATEST__TESTNODECOMPOUND_SAVE2 (this=0xb7a77a68) at NodeData_test.pas:408
#9 0x0821abf1 in FPCUNIT_TTESTCASE_$__RUNTEST ()
#10 0x0821ab38 in FPCUNIT_TTESTCASE_$__RUNBARE ()
#11 0x0821ba67 in FPCUNIT_PROTECTTEST$TTEST$TTESTRESULT () #12 0x0821bb61 in FPCUNIT_TTESTRESULT_$__RUNPROTECTED$TTEST$TPROTECT () #13 0x0821ba9e in FPCUNIT_TTESTRESULT_$__RUN$TTESTCASE () #14 0xb7a77a68 in ?? ()
#15 0xb7a7cb68 in ?? ()
#16 0x0821aaeb in FPCUNIT_TTESTCASE_$__RUN$TTESTRESULT () #17 0x0821b4f1 in FPCUNIT_TTESTSUITE_$__RUNTEST$TTEST$TTESTRESULT () #18 0x083ee660 in _$FPCUNIT$_Ld19 ()
---Type <return> to continue, or q <return> to quit--- #19 0x0821b4cb in FPCUNIT_TTESTSUITE_$__RUN$TTESTRESULT () #20 0x00000007 in ?? ()
#21 0xb7a7cb68 in ?? ()
#22 0xb7a77808 in ?? ()
#23 0x00000000 in ?? ()
(gdb)

-------------- Finish ----------------

Graeme Geldenhuys ha scritto:

Hmm, no idea where the problem is, can you send me the example that shows the av, maybe with the code I can find it.
Dean