[fpc-devel] FPCUnit problem - do we fix or rewrite?

[Dean Zobec]

Graeme Geldenhuys pravi:
> Hi,
>
> I use FPCUnit extensively at work and in open source projects like
> tiOPF, but I hit a bit of a snag - actually a bug in FPCUnit which
> causes many tests to fail for the wrong reasons. Here is one such case
> - in the tiOPF project many database tests fail do to "Setup Once"
> issues: http://opensoft.homeip.net/tiopf/fpcunit/index.html
> Michael van Canneyt has also hit this bug before, but now I'm not sure
> what exactly to do about it.
>
> The bug has to do with running a "setup" or "teardown" only once. Yes
> FPCUnit has the TestDecorator which adds this support, but if you have
> a nested test hierarchy, the running once falls over. When doing unit
> tests that share DB connections this issues becomes a major pain.
>
> Michael had a more in-depth look at the issue and told me that the
> problem lies in the heart of FPCUnit's design and is not very easy to
> solve. So much so, that he recommends it is better to simply rewrite
> FPCUnit than try and patch the existing code. I have not taken such a
> close look to the issue, but had to modify my test hierarchy to get
> around the problem (which should really not have been needed in the
> first place).
>
> Michael, do you still feel the same way about this issue?  Dean Zobec,
> are you still around? FPCUnit was your baby to start with. Do you have
> any comments?
>   
FPCUnit was a port of JUnit, actually a clone in Free Pascal.
The Setup and Teardown run only once for a set of tests goes against the
philosophy of unit testing actually, as violates the priciple that all
the unit tests should be independent from each other. The feature was
added as a decorator in JUnit for some marginal cases, with a very "use
with care" labeled on it. Where the class under test has strong
dependencies on other classes or the other classes are heavy to
construct in the usual Setup run for every test, I think it's about time
to use Mock Objects.

Anyway the code is quite old, JUnit evolved with the use of interfaces
and annotations and fpcunit stood still. I think annotations (in NUnit
and JUnit 4) were a big improvement as the tests can be inserted in any
class, without a need of inheriting from a TTestcase.

I'm sorry but I have no spare time at the moment to participate in any
serious development process, so I can only take a look from time to time
to give some suggestions and recommendations.

Dean



> I'm at cross-roads now. Do I try and solve the problem using the
> current code, or do I collaborate with Michael and Dean (and anybody
> else interested) and start a rewrite? If a rewrite is the preferred
> option, I have a few questions
>
>   * how will this affect all the existing FPCUnit users?
>   * will (or must) the new design have a similar API so our existing
> test suites will continue to run.
>   * Do we make it more DUnit compatible? I already created many DUnit
> compatibility methods, but some things are not possible.
>   * DUnit2 (hosted in the tiOPF code repository and written by the
> late Peter McNab) has some major improvements over the existing DUnit.
> Do we incorporate/port that, or merge the DUnit2 code into a new
> testing framework that is FPC and Delphi compatible?
>   * Obviously a timeframe is also important
>   * Do we use Interfaces (like DUnit and DUnit2) or do we use abstract
> classes like FPCunit currently does.
>
>
> Regards,
>   - Graeme -
>
>
> _______________________________________________
> fpGUI - a cross-platform Free Pascal GUI toolkit
> http://opensoft.homeip.net/fpgui/
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
>