Rolf wrote:

> Vitaliy wrote:
>> Rolf wrote:
>>   
>>>> I think you just created a straw man. :) I've never heard anyone
>>>> recommend writing a test program for the test program. What you
>>>> have is the program under test (the part that the users use), and
>>>> the tests. 
>>>> 
>>> Thinking of two examples: 
>>> 
>>> how do you test the accuracy of your new whizz-bang ultra-accurate
>>> pressure sensor ..... somehow you have to build an even more
>>> accurate pressure container... 
>>
>> I think this is like comparing apples and banana pies.
>>   
> Your original assertion wash that the tests are simpler than the
> program. Why is this comparing apples and banana pies?

I agree with Rolf. This is a good example of the test environment being 
more complex than the DUT. And it is such a common scenario.


>>> how do you test a software implemented queue that is accessed in a
>>> multi-threaded environment for both adding to and removing from the
>>> queue... 
>> 
>> You write functions that put something in the queue, and other
>> functions that pull stuff from the queue. What's complicated about
>> it? 

Ouch... :) The problem is not in the simple case of just putting in to 
and pulling out from the queue -- in a single-threaded environment, this 
is a task for students in an early semester. The problem is testing that 
it works well in multi-tasked environments, and the different timings. 
This is far from trivial. Try it sometime... create a queue that works 
in a multi-threaded environment and a test harness for it that tests 
whether it works correctly in a multi-threaded environment. I'm sure 
you'll find that the test requires much more effort and analysis. It's 
not only preventing harmful situations (which is what you need to think 
about when creating the queue), it is about creating them -- and 
creating all sorts of potentially tricky situations, not only the ones 
that are tricky for this specific implementation, but for the problem 
per se. (The test shouldn't depend on specific implementation details, 
it should test the correctness of the DUT based on the requirements, not 
the implementation.)


> I can see how at face value it may seem simple, perhaps the example is 
> trivial. 

It may seem trivial, but it isn't. You know that :)

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist