Invisible wrote:
>> Normally, a "unit test" covers what would normally be one class, and 
>> not a whole operation.
> 
> Again, depends what you test.

Well, I'm kind of taking the definition of "unit tests" as I understand it. 
There are four or five other kinds of tests too.

>> I can imagine lots of tests for a postscript parser: The string "one 
>> two three" parses into three words, the word "three" winds up on top 
>> of the stack, that "1.0" parses as a number but "1X0" doesn't, etc.
> 
> That's the kind of thing I'm trying to do. Except that figuring out 
> every possible case is surprisingly hard.

Yes it is. That's why you need to do it. :-)  Run it thru a 3rd-party 
postscript interpreter if you don't know what the function is supposed to 
be. You don't have to test exhaustively. You just have to figure it out.

Look, you have to figure out every possible case to *write* the code, yes?

> I'm having difficulty figuring out a way to really thoroughly check that 
> this works properly. Seemingly you'd need a really big stack of test 
> cases, but how do you generate those? 

While it's not what most people recommend, you can write the test cases as 
you write the code. When you add a check that looks to see if the first 
character is a digit and if so takes a different branch, you put in a test 
where the first character is a digit and where the first character isn't. 
For example.

Better would be to start with a dozen cases you know the answer to, then 
parse them until they work, and every time you see something funny or think 
of something new, add it to the list of test cases.

It's difficult to exhaustively figure out what you're going to match if you 
don't have the right formal tools. (This is why people like regular 
expressions and BNF, you see.)

 > (And how do you figure out what
> the "correct" answer is? This is sometimes non-obvious.)

If you can't tell from the spec, you have to run it against someone else's 
implementation. If you're attempting to build a compatible implementation, 
it has to match Adobe's(?) regardless of what the spec says.

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

>> That's the kind of thing I'm trying to do. Except that figuring out 
>> every possible case is surprisingly hard.
> 
> Yes it is. That's why you need to do it. :-)  Run it thru a 3rd-party 
> postscript interpreter if you don't know what the function is supposed 
> to be. You don't have to test exhaustively. You just have to figure it out.
> 
> Look, you have to figure out every possible case to *write* the code, yes?

Yeah. But you sit down and write some code which you think should work, 
and then you have to write lots of test cases for

- Does it fail on a zero-length literal name. [The spec explicitly 
*allows* such names.]
- Does it correctly handle [what would otherwise be] comments inside a 
literal string?
- Does it choke if the input contains a comment [and so is non-empty] 
but no further actual tokens?
- Does it parse all possible reals, but not invalid ones such as "." and 
"e1"?
- Does it handle balanced brackets and escaped brackets in strings?

It's easy to *think* you got all these working, only to suddenly 
discover that in some sufficiently obscure case it falls over. :-/

>> (And how do you figure out what
>> the "correct" answer is? This is sometimes non-obvious.)
> 
> If you can't tell from the spec, you have to run it against someone 
> else's implementation. If you're attempting to build a compatible 
> implementation, it has to match Adobe's(?) regardless of what the spec 
> says.

I'm not aware of any Adobe implementation that's freely available. 
(Except perhaps for the one inside the nearest laser printer. And I 
already tried to get that to parse stuff; it didn't seem to want to do 
it for some reason.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
>> Look, you have to figure out every possible case to *write* the code, 
>> yes?
> 
> Yeah. But you sit down and write some code which you think should work, 
> and then you have to write lots of test cases for
> 
> - Does it fail on a zero-length literal name. [The spec explicitly 
> *allows* such names.]
> - Does it correctly handle [what would otherwise be] comments inside a 
> literal string?
> - Does it choke if the input contains a comment [and so is non-empty] 
> but no further actual tokens?
> - Does it parse all possible reals, but not invalid ones such as "." and 
> "e1"?
> - Does it handle balanced brackets and escaped brackets in strings?

There's a good start. Why do you think it's hard?

> It's easy to *think* you got all these working, only to suddenly 
> discover that in some sufficiently obscure case it falls over. :-/

Testing doesn't prove the absence of bugs, only the presence of bugs.

> I'm not aware of any Adobe implementation that's freely available. 

Ghostscript would probably do pretty close, then. :-)

> (Except perhaps for the one inside the nearest laser printer. 

That one was far from free. :-)

> already tried to get that to parse stuff; it didn't seem to want to do 
> it for some reason.)

Sometimes you need to wrap it up in actual page description stuff, by which 
I mean the magic comments that mark the start and end of pages and such.

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

Darren New wrote:
> Orchid XP v8 wrote:
>>> Look, you have to figure out every possible case to *write* the code, 
>>> yes?
>>
>> Yeah. But you sit down and write some code which you think should 
>> work, and then you have to write lots of test cases for
>>
>> - Does it fail on a zero-length literal name. [The spec explicitly 
>> *allows* such names.]
>> - Does it correctly handle [what would otherwise be] comments inside a 
>> literal string?
>> - Does it choke if the input contains a comment [and so is non-empty] 
>> but no further actual tokens?
>> - Does it parse all possible reals, but not invalid ones such as "." 
>> and "e1"?
>> - Does it handle balanced brackets and escaped brackets in strings?
> 
> There's a good start. Why do you think it's hard?

Because the list is wildly incomplete. Figuring out how to make a 
*complete* list is absurdly hard.

> Testing doesn't prove the absence of bugs, only the presence of bugs.

Sure. But I'd like to reveal as many bugs as possible, so...

>> I'm not aware of any Adobe implementation that's freely available. 
> 
> Ghostscript would probably do pretty close, then. :-)

Yeah, that's what I'm ending up using. (Ghostscript seems to correctly 
process just about every *real* page description I've ever come across, 
so I guess it's not too bad a comparison.)

>> (Except perhaps for the one inside the nearest laser printer. 
> 
> That one was far from free. :-)

Ah, but for me? ;-) I didn't pay...

>> already tried to get that to parse stuff; it didn't seem to want to do 
>> it for some reason.)
> 
> Sometimes you need to wrap it up in actual page description stuff, by 
> which I mean the magic comments that mark the start and end of pages and 
> such.

Nope. If I send it a PostScript program that draws some coloured lines 
and stuff, it spits out a piece of paper with lines drawn on it. If I 
send it another PostScript program [which also works fine in 
Ghostscript] that parses a string and writes the results onto the 
page... the printer appears to not receive the data. Really weird.

(And if I send a PostScript program containing deliberate errors, the 
printer prints out a page with an error message on it.)

Post a reply to this message

Invisible wrote:
> Ghostscript] that parses a string and writes the results onto the 
> page... the printer appears to not receive the data. Really weird.

You invoked showpage and all that stuff, I assume?  (Along the "is it 
plugged in, is it turned on" kind of debugging?)

Take a page that just prints one bit of text, and edit it with notepad or 
whatever you prefer, and see if you can get a base for printing?

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> Ghostscript] that parses a string and writes the results onto the 
>> page... the printer appears to not receive the data. Really weird.
> 
> You invoked showpage and all that stuff, I assume?  (Along the "is it 
> plugged in, is it turned on" kind of debugging?)
> 
> Take a page that just prints one bit of text, and edit it with notepad 
> or whatever you prefer, and see if you can get a base for printing?

As I say, when I run it in Ghostscript, it works just fine. But it 
doesn't seem to want to work on the laser printer I tried it with. (I 
guess I could try another...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> As I say, when I run it in Ghostscript, it works just fine.

I don't know how ghostscript works per se. You're sending it to the printer, 
or the screen?

The point is the PS interpreter in the printer has no good way of knowing 
you're done with the page, unlike ghostscript, so you have to add specific 
code to the postscript on a printer to say "I've generated the bitmap, so 
send it to a page now."  IIRC, that command is called "showpage".

Ghostscript on the screen renders as it interprets, so that's different.

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

Darren New wrote:
> Orchid XP v8 wrote:
>> As I say, when I run it in Ghostscript, it works just fine.
> 
> I don't know how ghostscript works per se. You're sending it to the 
> printer, or the screen?
> 
> The point is the PS interpreter in the printer has no good way of 
> knowing you're done with the page, unlike ghostscript, so you have to 
> add specific code to the postscript on a printer to say "I've generated 
> the bitmap, so send it to a page now."  IIRC, that command is called 
> "showpage".
> 
> Ghostscript on the screen renders as it interprets, so that's different.

Ghostscript also refuses to display anything until you perform a 
showpage operation. (Or the deprecated copypage operation, for that matter.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> Because the list is wildly incomplete. Figuring out how to make a 
> *complete* list is absurdly hard.

Actually, the right answer is to start with the incomplete list, and make 
sure that nothing that used to work breaks when you add more.

But the real point of this post: A sample unit test for you:

http://groups.google.com.au/group/comp.lang.misc/msg/6167f34c7fff9570

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> Because the list is wildly incomplete. Figuring out how to make a 
>> *complete* list is absurdly hard.
> 
> Actually, the right answer is to start with the incomplete list, and 
> make sure that nothing that used to work breaks when you add more.

Well, that too.

> But the real point of this post: A sample unit test for you:
> 
> http://groups.google.com.au/group/comp.lang.misc/msg/6167f34c7fff9570

Ooo... TMFT? ;-)

Post a reply to this message