Hi Dean,
Thanks for getting back to me on this.
Dean Zobec wroteThe table of published method's names is implemented differently in FPC.
See testutils.pp in the fpcunit directory for a simple way to get
I will take a look shortly, to educate myself a bit more. :)
Sure, FPCUnit follows closely JUnit in the implementation and it's
interface. But IIRC the only difference that is substantial is in the
naming of the assertion methods and the fact that the assertions are
Yeah, I wrote a DUnit compatible interface for fpcUnit, to help me along. The project I am porting is the TechInsite tiOPF Framework, which we use for our companies products. After my conversion, tiOPF still needs to compile under Delphi, hence the compatibility layer, and I want to share as much code as possible. eg: If they add a new test under Delphi, it must run under fpcUnit as well without me needing to do anything.
Maybe we can include the DUnit compatible interface as part of fpcUnit? It will come in handy for cross platform/compiler projects that have existing DUnit tests, like in my case.
But I would prefer to understand the things that makes you consider the
need of switching to DUnit.
I gave it a bit more thought last night (I think I had one of those bad programming days yesterday). I came to the conclusion that it isn't really a limitation in fpcUnit, but my lack of understanding of the code I am trying to port. The setup of multiple DB Connections for the different persistence layers using a single TestDecorator as an abstract class. I will ask the tiOPF community for some help.
Have you find some substantial limits in
FPCUnit, is there anything that you suggest it should be implemented
differently? I would like to have some feedback from the users so that
we could improve FPCUnit.
Seeing that you asked, I have a few suggestions for the GUI Testrunner. ;)
* Keep the treeview in the same state and position after a test has been run. As I mentioned, I have a lot of tests. I close some tree nodes, to find the suite of tests I am looking for. If I run any test, the treeview gets redrawn and all nodes get expanded again. This must be the single biggest annoyance for me.
* Save the size/position/state of the GUI Testrunner form to a INI or XML file, so when the Testrunner is run at a later time, it remembers its previous size/position/state. Again, this is due to the amount of tests I have, so I always resize the window to see more tests at a time. This is easy, so I can implement this myself and send a patch. I already submitted a patch to help with the treeview resize issue a while back.
* What I miss from DUnit, it the check boxes on the treeview. I know this goes against the Unit Testing principals of always running all tests, but it is handy for running a quick set of tests while developing on a small part of code. All tests get run in the nightly builds anyway. You can select which set of tests you want to run, and only run those which are checked. The GUI Testrunner can save that set to a INI or XML file for later use again.
* I really like the results as XML! It makes it handy for posting the result to the web (nightly builds) and use a stylesheet for nice formatting in columns, etc. Is it possible to auto save those result to a file?
The only larger project that I know it's using
FPCUnit it's the Delphi InstantObjects project (I made a special
backport to Delphi just for them:):
http://www.instantobjects.org/ and
So they can compile fpcUnit under Delphi as well? I remember looking at InstantObjects a year ago. I wonder how far they are with the FPC port.
Thanks for your time.
Regards,
- Graeme -