[vtk-developers] testsetget/emptyinput etc

[David Cole]

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/84fe29fa/attachment.html>