POV-Ray : Newsgroups : povray.off-topic : Unit testing - simple question with long explanation for discussion... : Re: Unit testing - simple question with long explanation for discussion... Server Time
6 Sep 2024 11:18:20 EDT (-0400)
  Re: Unit testing - simple question with long explanation for discussion...  
From: Darren New
Date: 8 Jan 2009 12:39:03
Message: <49663a37@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.