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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
