[fpc-pascal] FPCUnit: TestSuiteName vs TestName

[Dean Zobec]

Graeme Geldenhuys pravi:

> Looking into the DUnit code I found the reason for passing in the
> name. It's actually a Suite Path used to automatically create
> TTestSuites for you so you can better group you tests case in a
> hierarchy.  You would use it if you don't want the registered test
> case to appear in a top level node (like in the GUI Runner).

Yes, the registration unit in FPCUnit is very simple, I've actually
included it as an example on how to add the test suites more than a set
of utility classes. In fact you get the root test suite through
GetTestRegistry function and then you add any hierarchy you wish just by
 creating other suites and building the tree. So your unit is very handy
for this and spares some typing.

> I have implemented the same functionality for FPCUnit (a overloaded
> RegisterTest method) today.  See my other message to this mailing
> list.  I'll create a patch for it tomorrow and see if it will make it
> into 2.2 branch but I doubt - which will be a pitty as it is very
> useful and helps a lot in a huge test suite like tiOPF has.
> 
Yes, if it wasn't for your huge test suite, FPCUnit would not have been
improved. The first time I've heard from you, some two years ago I
didn't even believe it could handle such a suite gracefully.
There is still many improvements that can be made, but my spare time is
quite scarce lately. I'm waiting for my vacations :)


> DUnit is also based on JUnit. They just followed the path using
> Interfaces instead of abstract classes.  In the end they are very
> similar I think.
I agree, the differences are not many, and not important, except for the
 assert methods that are class methods in JUnit and FPCUnit.

> 
>> TTest is an abstract class, TTestSuite is a composite pattern. Just look
>> at the JUnit documentation, here you can find a UML diagram:
> 
> Thanks, I'll take a look at those links. I'm sure they will come in handy.

You need them if you want to understand the internals. JUnit is a live
demonstration that flexibility in OOP design leads to code that is very
difficult to understand, due to the many indirections.
But I guess in this case it's justified by the fact that the framework
had to be also easy to use and had to spare on typing by the end user.
Only when I wrote myself the framework in pascal, following the java
code, I was able to understand it completely (and still I'm convinced
that after so much refactoring on the junit side, some indirections were
redundant).

regards,
Dean