test suite: Add tests for undefined page range limits

[zdohnal]

Originally pdftopdf from cups-filters doesn't support page range with
undefined upper limit (f.e. '5-'), but I found out these page ranges
aren't checked in CUPS test suite neither.

It would be great if we could cover the use case in test suite to
prevent possible regressions in the future.

[zdohnal]

Currently you cannot verify if it works because the commit from #201 broke the test suite. More info in the ticket.

[zdohnal]

But I applied the PR on the commit before the commit from #201 locally, ran the test suite and it passed, so it could suffice for verification.

[michaelrsweet]

@zdohnal What were the errors you were seeing? The page-ranges attribute should only be encoded as a rangeOfInteger, with an undefined lower limit getting a value of 1 and an undefined upper limit getting a value of INT_MAX (2^31-1).

I have no problem with adding a test for this (and I should probably add some unit tests to make sure each option is encoded as expected in libcups) but the filters should never see "N-" or "-N", just "N-2147483647" and "1-N".

[zdohnal]

I have no problem with adding a test for this (and I should probably add some unit tests to make sure each option is encoded as expected in libcups)

It would be great - it's on my TODO list to do the similar thing, especially in cups-filters, where conversion from filter executables to filter functions is happening and it would be great if we had means to check about regressions.

but the filters should never see "N-" or "-N", just "N-2147483647" and "1-N".

pdftopdf saw "N-2147483647" and interpreted it as "1", so the whole document was printed instead of N- (see cups-filters PR). I see pstops filter is the only filter in CUPS which does page range checking and it does not show the issue.
But as I think about it, it would be great if we have specific tests for filters as well, instead of counting on libcups will provide sane inputs. I'll enhance the PR.

[zdohnal]

But as I think about it, it would be great if we have specific tests for filters as well, instead of counting on libcups will provide sane inputs. I'll enhance the PR.

Actually, I'll rather create a separate PR for it.

[zdohnal]

@michaelrsweet The filter tests will come in the future PR, would you mind merging this PR in the meantime?

P.S. The error reported by Codacy looks bogus - $runcups and $VALGRIND vars don't contain multiple words, so it is okay - however I'm curious why this isn't reported on all usages of the vars, because they are in every command in the test suite.

[michaelrsweet]

@zdohnal I want to spend a little more time reviewing things before I merge. Test suite changes like this can have unintended consequences... :/

[zdohnal]

@michaelrsweet ok, no problem, take your time - my comment before that could implicate that there will be more stuff coming into the PR, so I wanted to make sure that you aren't waiting on me :) .

[michaelrsweet]

OK, let's clean up the "expected" count here and then merge. I'll look at a way to automate the expected request calculations.