[vtk-developers] testsetget/emptyinput etc

[David Cole]

Not that I'm one of the ancient ones, yet...... :-)


On Fri, Sep 28, 2012 at 5:32 PM, David Cole <david.cole at kitware.com> wrote:

> Most of the time, when the Tcl SetGet test fails on a new change, it is
> that somebody has added a pointer ivar, and initialized it to "NULL" or 0,
> and then it is accessed in a Get method without being checked.
>
> This test helps to catch things like that, and usually, the correction is
> just to add an "if ()" test that verifies the pointer is non-null before
> dereferencing.
>
> All VTK devs need to understand that methods are called (by various people
> in the real world) in an order different than the one they expect. Just
> because the new test that they wrote does it correctly doesn't mean anybody
> else will.
>
> This test helps to make all the methods robust no matter what order they
> are called in.
>
>
>
> On Fri, Sep 28, 2012 at 5:22 PM, David E DeMarle <dave.demarle at kitware.com
> > wrote:
>
>> Thanks.
>>
>> I'm looking for more details.
>>
>> Specifically why is it a bad thing when each of our specific smoke tests
>> fail on some new code and when exceptions for that test are acceptable.
>>  On Sep 28, 2012 4:26 PM, "Bill Lorensen" <bill.lorensen at gmail.com>
>> wrote:
>>
>>> Dave,
>>>
>>> "Ancient ones"?  We prefer "Wise ones"...
>>>
>>> These are smoke tests: http://en.wikipedia.org/wiki/Smoke_testing
>>>  to blinding test basic functionality. They certainly matter.
>>>
>>> For example SetGet tests ensure that a variable can be set  and
>>> retrieved. In the past we had tests that ensured that if a variable was
>>> changed, the class' modified time changed. Or, can a class print itself
>>> after instantiation.
>>>
>>> Bill
>>>
>>> Sep 28, 2012 at 4:10 PM, David E DeMarle <dave.demarle at kitware.com>wrote:
>>>
>>>> Could one of the ancient* ones on the list explain the rationale
>>>> behind these and the other old tcl style tests?
>>>>
>>>> They are failing now in some of the new classes that were
>>>> added/changed during the big test downtime that started when
>>>> modularization went in. Before I get deep into the job of fixing them
>>>> (or convincing the responsible parties that they should), I'ld like to
>>>> know if and why they matter.
>>>>
>>>> thanks,
>>>>
>>>> *I'm not mentioning any names here Will.
>>>>
>>>> David E DeMarle
>>>> Kitware, Inc.
>>>> R&D Engineer
>>>> 21 Corporate Drive
>>>> Clifton Park, NY 12065-8662
>>>> Phone: 518-881-4909David E DeMarle
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>
>>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>>>
>>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120928/4ab22293/attachment.html>