[fpc-pascal] FPCUnit: TestSuiteName vs TestName

[Dean Zobec]

Graeme,
> Hi,
> 
> When would you use TestSuiteName and when TestName?
TestSuiteName is the name of the TestSuite (parent) that contains the Test

> 
> For example, the following I think is wrong.
> 
> constructor TTestSuite.Create(AName: string);
> begin
>  Create();
>  FName := AName;
> end;
> 
> Shouldn't this set the FTestSuiteName field?
No, FTestSuiteName is set only when the Suite is added to another TestSuite:

we have
procedure TTestSuite.AddTest(ATest: TTest);
begin
  FTests.Add(ATest);
  if ATest.TestSuiteName = '' then
    ATest.TestSuiteName := Self.TestName;
end;

The ATest parameter can be a TTestCase or a TTestSuite

> Now if I do a TestSuite.TestSuiteName it doesn't return FName, instead
> it returns FTestSuiteName.  If I do a TestSuit.TestName it returns the
> FName.
> 
> This problem seems to be confirmed with the following code:
> 
> constructor TTestSuite.Create(AClass: TClass; AName: string);
> begin
>  Create(AClass);
>  FName := AName;
> end;
> 
> 
> This is getting very confusing. When are we supposed to use
> TestSuiteName and when do we use TestName?
> 
> 
> For example in DUnit you can register a test as follows:
>  RegisterTest(cSuiteNameNonPersistentTests, ATestCaseClass.Suite);


FSuiteName is handled automatically when the TTest descendent is added
to a TestSuite, you don't have to set it manually.



> So if I want to implement this in FPCUnit, what name am I supposed to set?
> 
> Maybe I'm just getting confused with the difference between TTest,
> TTestCase and TTestSuite. I go read some more on this in the DUnit web
> page (do we have FPCUnit docs explaining this?).
FPCUnit has a different structure then DUnit, is a literal port of the
JUnit test framework, with only some changes that were required to adapt
the Java code (callbacks instead of inner classes in some places iirc).
TTest is an abstract class, TTestSuite is a composite pattern. Just look
at the JUnit documentation, here you can find a UML diagram:

http://junit.sourceforge.net/doc/cookstour/cookstour.htm

and there is a good chapter available as an MIT Lecture on OOP and
patterns that takes the JUnit framework as a Case Study:
http://courses.csail.mit.edu/6.170/old-www/2001-Fall/lectures/lecture-17.pdf

I choose to adhere strictly to the JUnit framework as it was a standard
when the FPCUnit port was created, and no additional documentation of
the framework was needed (you could always refer to the JUnit
documentation and practice, a lot of articles and books were written on
the subject).

Still, it's not a good excuse for lack of documentation :)

Regards,
Dean