All the Perl that's Practical to Extract and Report

More on the WriteExcel port

djberg96 on 2002-08-22T18:20:20

I think I've finished porting the first of the Spreadsheet::WriteExcel modules, called OLEWriter.

I say I think, because I'm not sure how to test it. At first I thought I could just steal John's own tests and slap them into Ruby's Test::Unit module or something.

But then I realized....there *aren't any tests*! I'm not upset or anything (that would make me a blithering hypocrite, if nothing else), but I *am* surprised.

I'm surprised because it seems like for a module of this complexity there would be a lot of room for little errors, especially with all of the specific hex values you have to use. There must have been quite a bit of trial and error, then.

Spreadsheet::WriteExcel test

jmcnamara on 2002-08-23T08:43:22

In the CPAN distribution of Spreadsheet::WriteExcel there is only has one real test and that is to determine if the hardware supports a 64 bit IEEE float.

The reason that there aren't more tests is that there isn't any way to test the module apart from creating a file, opening it in Excel, checking if the required features are okay and then closing it again. This isn't something that can be automated on a cross-platform basis.

It would be possible to generate an Excel file, MD5 the results and check it against a known value. However, this would be artificial.

This is not to say that the module hasn't been tested. I spent over 3 months on the development and testing of OLEwriter.pm alone. This involved creating binary files of various N, N-1, N+1 sizes, storing them with OLEwriter and then reading them with 3 versions of Excel on Windows, MS Works on Windows and OpenOffice, Gnumeric and Xess on Linux.

For each feature that is added to Spreadsheet::WriteExcel I have to go through a similar process. This, and the documentation, is what makes progress so slow. But again, it would be difficult to include these type of tests in the CPAN distribution.

In a way the 40+ example files are the tests. They serve as unit tests and as regression tests. And Excel is the arbiter of whether the module works or not.

The best way to test your ported version is to compare the binary output with the output of Spreadsheet::WriteExcel and ensure that there is byte-for-byte equivalence. In that way you will inherit my bugs but also my testing. :-)

John.
--

Re:Spreadsheet::WriteExcel test

djberg96 on 2002-08-23T12:48:32

Heh - caught me.

I guess what I expected to see were tests where you write particular strings and numbers to a cell or group of cells, then check to see if the values written to the file are what you expect (like an "od" check or something). I realize that this is somewhat artificial, but it would at least let you know if you had made any *obvious* errors.

I realize the acid test is to just open the file in Excel and see if it worked. I was just hoping there would be some intermediate testing I could do. :)

Re:Spreadsheet::WriteExcel test

chromatic on 2002-08-23T14:41:43

The reason that there aren't more tests is that there isn't any way to test the module apart from creating a file, opening it in Excel, checking if the required features are okay and then closing it again.

I will tell you something that is true: that sounds like a dare. (I do have plenty of tasks already.)

Re:Spreadsheet::WriteExcel test

jdavidb on 2002-08-23T16:05:53

I test it all the time. Seems to work great! :)