Any Laz dev bored with discussions about how to share file uploads or what splash screen is best?

If so, you can relieve your boredom by implementing the patch in 24251 [Patches] [patch] fix for fpcunit gui testrunner stopping with exception

Thanks ;)

Reinier

2013/4/15 Reinier Olislagers

Any Laz dev bored with discussions about how to share file uploads or what splash screen is best? What discussion? I have yet little time, so I might have missed

something...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130415/44c810a3/attachment.html>

The file sharing discussion on this list; the splash screen stuff on the forum...

Reinier Olislagers wrote

If so, you can relieve your boredom by implementing the patch in 24251 [Patches] [patch] fix for fpcunit gui testrunner stopping with exception

I hope you wrote a unit test to test that exception [for regression testing of course]. ;-)

Regards,
- Graeme -

Mmm yes....
I hope somebody has a patch for the underlying with either fpcunit, guitestrunner or the xml code, or whatever it is that screws with the results ;)
My crystal ball is whispering that both of our expectations won't be met quickly :)

Reinier Olislagers wrote

I hope somebody has a patch for the underlying with either fpcunit, guitestrunner or the xml code, or whatever it is that screws with the results ;)

Have you tried FPTest (DUnit2 fork) yet? FPCUnit has a DUnit compatible interface - so switching between the two is easy. I did this for years with tiOPF.

My crystal ball is whispering that both of our expectations won't be met quickly :)

:-)

Regards,
- Graeme -

No. See the bugreport in my first post. I have no interest in trying to get fptest into fpc.

Reinier Olislagers wrote

No. See the bugreport in my first post.

I did see it.

I have no interest in trying to get fptest into fpc.

Not what I suggested. I suggested using a better and more reliable unit testing framework - but keeping backwards compatibility with FPCUnit by using the DUnit interface to tests (CheckXXX() methods instead of AssertXXX() methods).

I've been a very long user and contributor of FPCUnit, and it is a very problematic framework.

Regards,
- Graeme -

Let's not exaggerate the problems.

I use it for years, and except for 1 issue, there are no problems. Yes; this one issue is hard to solve. But other than that it works as a test framework should work.

Michael.

2013/4/15 Michael Van Canneyt :

For the record, can you point what is this issue?

Luiz

If you specify 1 test to be executed, part of a suite, and there is a test-decorator for the suite, then the test-decorator is not executed.

for example:

Database
Database.TestObjectA.TestInsert
Database.TestObjectA.TestDelete
Database.TestObjectA.TestUpdate

if there is a testdecorator TConnectToDatabase
for suite Database and I specify --suite=Database.TestObjectA.TestInsert then this decorator is not used.

Other than that, I have literally thousands of tests: no problems.

Michael.

Michael Van Canneyt wrote

I use it for years, and except for 1 issue, there are no problems.

Yes the issue you mentioned, plus other decorator issues too. I remember having problems where decorators executed too many times too, in nested tests - causing large test suites to slow down dramatically.

Then there is also the lack of controlling test runs, configurable options, project support inside a test suite, lack of warnings about tests that don't actually call any AssertXXX() methods, more accurate timing (excluding Setup/Teardown times), summary level check support to speed up test suite execution when needed (thus skipping detail level tests) but if the summary test fails then detailed tests will run, memory leak detection and overriding what is acceptable leaks etc etc... Then I haven't even gotten to the GUI and Console runner features.

The list is much larger than just 1 issue. You should take a look at DUnit2/FPTest at some point to see just how far behind FPCUnit is in functionality. FPCUnit development has been dormant for years, and my (and many others) testing needs have grown far beyond what FPCUnit offers.

But yes, if you have a very basic test suite design, or have very basic testing needs, then FPCUnit should suffice I guess.

Regards,
- Graeme -

2013/4/15 Graeme Geldenhuys :

The list is much larger than just 1 issue. You should take a look at DUnit2/FPTest at some point to see just how far behind FPCUnit is in functionality.

Where can we find it?

Any docs?

Is there a GUI runner?

I'm starting now in test world. If i can base my work in a more solid framework, it's better.

Luiz

luiz americo pereira camara wrote

Where can we find it?

FPTest
https://github.com/graemeg/fptest

DUnit2
http://sourceforge.net/projects/dunit2/

Any docs?

There are some docs in each repository, there are also example projects included, plus the DUnit v1 docs also apply to these frameworks.

Is there a GUI runner?

Yes, for VCL and fpGUI. I haven't created a LCL one yet. The Console runner also works very well.

Regards,
- Graeme -

Exactly. That is the only problem I am aware of.

Then there is also the lack of controlling test runs, configurable options, project support inside a test suite, lack of warnings about tests that don't actually call any AssertXXX() methods,

I have lots of such methods ?

   if xyz then
     fail()

Memory leak detection is a global problem, addressed in heaptrc. By definition, the testsuite cannot do anything about that.

Then I haven't even gotten to the GUI and Console runner features.

These are not 'problems'.

They are features you happen to miss. Nothing wrong with missing those, but they are not "problems".

So please be more correct in your wording.
What you wrote amounts to spreading FUD, and that is the last thing we need.

Michael.

Uh... here is an example of what I am talking about.

---------------------
unit TestCase1;
{$mode objfpc}{$H+}
interface
uses
  Classes, SysUtils, fpcunit, testutils, testregistry;
type
  TTestCase1 = class(TTestCase)
  published
    procedure SilentFailure;
  end;
implementation
procedure TTestCase1.SilentFailure;
var
  i: integer;
begin
  i := 10;
  // Test doesn't actually call AssertXXX() or CheckXXX(), yet FPCUnit
thinks it passed
end;
initialization
  RegisterTest(TTestCase1);
end.
--------------------------

And here is the FPCUnit results..

graemeg at ubuntu:/tmp$ ./fpcunitproject1 -a --format=plain Time:00.000 N:1 E:0 F:0 I:0
TTestCase1 Time:00.000 N:1 E:0 F:0 I:0
00.000 SilentFailure

Number of run tests: 1
Number of errors: 0
Number of failures: 0

Yes a simple example, but this issue is very possible in complex tests, or if the developer got sidetracked. And note, FPCUnit reported no problems or here is the FPTest results:

graemeg at ubuntu:/tmp$ ./project2

FPTest / Testing
.W
Time: 00:00:00.000

OK: 1 tests
There was 1 warning:

1) project2.TMyTestCase.SilentFailure: EPostTestWarning at $00000000004001A0
No checks executed in TestCase

Regards,
- Graeme -

I understand, but then I'd be stuck with lots of useless warnings, since there is no way to differentiate a real from a false one.

Better no warnings than lots of false warnings.

Michael.

I don't understand you statement. What false warnings? The test didn't actually do any checks - so shouldn't be considered a valid test case.

FPCUnit reports: Errors and Failures.
FPTest reports: Errors, Failures, Warnings and Excluded Tests

The "no test executed" warnings can be toggled on or off at runtime too. So if you didn't want to see it, you don't have to - but it boggles the mind why you would want to hide such a test oversight. You can also tell the framework to promote "no test executed" warnings to test failures.

On a side note:
Excluded Tests are test that are individually excluded from a test run for whatever reason. The state is remembered even after you disable and re-enable a test class, test suite or test project. In console output they will be marked with an 'x' symbol. In the GUI treeview the test will have a red X symbol.

Regards,
- Graeme -

You didn't look at my example very careful.

I give it in simplified form:

Procedure TTestSomething.MyTest;
begin
   If (MyObject.MyProperty'') then
     Fail('MyProperty must be empty');
end;

For a string, you would probably use AssertEquals, but there are lots of cases where you cannot use AssertEquals, as there is nothing to be equal to.

The above kind of construct tests all it needs to test, yet does not call AssertEquals.

Since no AssertEquals is called, it will give a false warning in your test framework.

Michael.

r40832
Thanks for the commit, Mattias!