Darius Blaszijk wrote:
> Here's a patch for the guitestrunner form for fpcunit. I have added a synedit
> XML highlighter and done some anchoring.
Ok, good, Graeme can integrate this with his changes (his problem to
solve was related to the scrolling as the issue arose in his experience
with his huge number of tiOPF tests), and he will fix the xml standard
compatibility issue.
>
> Q: is fpcunit inspired on dunit or is it actually derived from some version
> of dunit? I have briefly glanced at dunit and I noticed that it has more a
> bit more functionality than fpcunit currently has. So my next question is do
> we want (need) this "more" functionalty or not? Do we want (need) fpcunit to
> be compatible with dunit?
No, fpcunit was built looking directly at the JUnit java code as
designed by Kent Beck and Erich Gamma. The core JUnit framework is a
good example of the OOP power (it was actually used as a case study in
some MIT OOP courses) so I tried to be as close as possible to the
original java code that has gone through years of refactoring and has
proven to be more flexible as DUnit (in particular cases like using the
asserts outside the TTestCase class and in data driven test cases as
used in sqldb tests by Joost.
However if you find some additional functionality that is present in
DUnit and is missing in FPCUnit please report it, we'll be happy to add
it if it's useful.
> I have also make a simple "maketestcase skeleton" app for existing projects.
> It reads the functions and properties from the implementation section using
> codetools and creates a skeleton unit, with a test case defined for each of
> the functions and units. If anyone is interested in this code I can send it.
> Perhaps it would be an idea to ship it with lazarus as a tool?
Good, it was the next addition I've planned. I was thinking to add a
choice in the starting dialog to chose whether to create empty skeletons
for the tests of the protected, public or published methods (some
checkboxes) as in Eclipse-JUnit integration, using the codetools for the
parsing of the interface of the classes under test.
My usual proceeding when coding new classes is in fact to write a
partial definition of the class first (I like to imagine how I would
like to interact with my new class), use code completion to create empty
stubs for the methods, write the tests for these methods and then start
the refactoring to improve it and remove the duplications. So, it's
handy to be able to have Lazarus to write the empty stubs for the tests
too, maybe even some setup or teardown code. So please send me the code
of your solution, I'll be happy to review it.
Thank you again for the patch,
Regards,
Dean
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
