| CC: | walde.christian [...] googlemail.com |
| Subject: | New lines break cross-OS compatibility |
Hi Nicholas,
Show quoted text
> Thanks for your contribution. I have noticed the behaviour you
> described though it never occurred to me to blame Test::Regression
> rather than windows. ;-)
To be fair, i blame Perl in this case and regard its insistence to
change my data as a bug.
Show quoted text> Testing should not be an issue. I can write some tests that are
> skipped on anything else than windows or some such strategy.
Great to hear, thanks. :)
Show quoted text> However I am not really convinced that binary mode is the right
> solution. Surely the issue is in the different newline representations.
> May be I should be normalizing the output so that the regression files
> are always taken to be in unix format?
Well, here's the thing, ok_regression takes two kinds of data:
1. the return of a function
2. file contents
And the problem (when doing cross-platform work) is that Perl itself
changes the newline format of file contents to match the system, but not
that of function returns.
So there are three ways to solve this:
1. change the function so it always returns system-relevant newlines
2. change the ok_regression so it changes the function return after the
fact to match the OS
3. change the file accessor functions so they always return the same
data no matter what OS they are on
It is my belief that option one is wrong, since it forces people to care
about things they likely do not care about.
Option two is acceptable, but has two problems: For one it changes data,
which could possibly lead to tests failing in non-obvious ways, or
actually changing the function of the test away from the intent. (For
example, what happens if you WANT mixed newlines in a file?) Secondly it
requires a reimplementation of the actions filehandle->read and
filehandle->print do internally, which i think is a waste of time and
effort and possibly a danger if the internal actions ever change. (I
think that actually happened once.)
Option three seems to be the most sensible to me because it allows the
developer to ask this in a very clear manner: Does my function output
*exactly* match the contents of the stored file?
Then again, i may be wrong, strawmanning or overlooking things, so feel
free to regard this merely as an opinion. :)
Show quoted text> Anyway the feature I most desire is the ability to step through the
> differences one by one and refresh the regression files on a case by
> case by case basis.
Easy. ;)
TEST_REGRESSION_GEN=1 prove
git add -p
Show quoted text> Is this holding up your CPAN upload?
Nah, I'm fine, i just added a copy with my changes to t/lib. Thanks for
asking though. :)
--
With regards,
Christian Walde