247456 - nsIFileTest needs to be updated to a full regression test harness

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, defect)

Description

[Brodie]

The current implementation of nsIFileTest doesn't provide automated testing of
the implementation of nsIFile and nsILocalFile. I've rewritten this over the
time I've been working on cleaning up the windows implementation and it is now a
fully automated test harness. It would be good to have this checked in and have
people actually update it once in a while with new tests...

Comment 1

[Brodie]

Attachment: patch

Patch version of the new nsIFileTest.cpp, although I don't think it is
particularly useful. The new version is a complete rewrite so I'll attach the
whole file as well.

Comment 2

[Brodie]

Attachment: file

Comment 3

[Darin Fisher]

the patch doesn't compile under Fedora Core 2... i just had to ifdef
TestMultiByteCollectionWin32 accordingly.  when i run the test i see
output that says that 2 tests failed:

  ---------------------------
  TestCopyMove
  ---------------------------
  NS_NewNativeLocalFile(/tmp/src.txt)
  NS_NewNativeLocalFile(/tmp/dst.txt)
  Exists() = 0, expected = 0
  Exists() = 1, expected = 0
  *** ERROR:   Test failed at line 413
  *** FAILURE: !exists
                                                                                
  ---------------------------
  TestCopyMove
  ---------------------------
  NS_NewNativeLocalFile(/tmp/src)
  NS_NewNativeLocalFile(/tmp/dst)
  Exists() = 0, expected = 0
  Exists() = 1, expected = 0
  *** ERROR:   Test failed at line 413
  *** FAILURE: !exists

indeed there is a directory at /tmp/dst, which appears to have been
created by the test.

Comment 4

[Brodie]

Actually, I don't have a Linux build environment at the moment, so the Unix 
version of this is pretty rough. I was hoping that a person with Unix build 
would help me out here (and OS/2 and ...) however no-one has been forthcoming, 
so I've just tried as best I can. I realize this isn't isn't good enough and 
hope to get a Linux build going within the next couple of weeks.

Comment 5

[Darin Fisher]

no worries... when i get some time i'll hack on the linux side and check in the
patch.  for reference, test programs can usually be modified in the tree without
much code review.  it's usually good to give the developers for the module a
heads up and a chance like you have to input some feedback.  i'm happy that you
are contributing these tests... it's much needed! ;-)

cc'ing OS/2 folks since this patch might cause OS/2 bustage.

Comment 6

[Brodie]

Does the build system run the tests at all or is it a manual process at the 
moment? The old test harness always returned 0. This one returns the number of 
test failures.

Comment 7

[Darin Fisher]

(In reply to comment #6)
> Does the build system run the tests at all or is it a manual process at the 
> moment? The old test harness always returned 0. This one returns the number of 
> test failures.

It is a manual process at the moment, but we could hook up the test to be run by
tinderbox after each build.  We'd just need to add a testcase to tinderbox's
build-seamonkey-util.pl.  Look in mozilla/tools/tinderbox, and if you can hack
perl it shouldn't be too hard to duplicate one of the other tests.  We should be
able to make it so that the test causes tinderbox to turn orange whenever it fails.

Comment 8

[Wayne Mery (:wsmwk)]

obsolete?