Graeme,
Hi,
When would you use TestSuiteName and when TestName?
TestSuiteName is the name of the TestSuite (parent) that contains the Test
Show quoted text 10 lines
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
Show quoted text 19 lines
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.
Show quoted text 5 lines
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
