[Cuis-dev] [IMPROV] Testing and Debugging Deprecated Methods

[Gerald Klix]

On 2020-10-01 15:22, Juan Vuletich via Cuis-dev wrote:
> Hi Gerald,
> 
> On 9/29/2020 2:43 PM, Gerald Klix via Cuis-dev wrote:
>>
>>
>> On 2020-09-29 17:08, Juan Vuletich via Cuis-dev wrote:
>>> On 9/28/2020 2:17 PM, Gerald Klix via Cuis-dev wrote:
>>>> Hi all, hi Juan,
>>>>
>>>> I suggested in another post to flag unit deprecated methods in unit 
>>>> tests.
>>>> Now I implemented the required changes.
>>>>
>>>> Please find a change set and small package with some unit test 
>>>> attached to this message.
>>>>
>>>>
>>>> HTH and Best Regards,
>>>>
>>>> Gerald
>>>
>>> Thanks Gerald.
>>>
>>> What do others think? Isn't it enough with keeping a Transcript open 
>>> when developing?
>>>
>>> Cheers,
>>>
>>
>>
>> Hi,
>>
>> The default behavior, printing some text on the
>> Transcript, can be changed easily by just changing the default value 
>> of one preference.
>> (openDebuggerOnDeprecationWarning).
>> Of course you can set this one to `true`.
>> which will open a PreDebugger-Window.
> 
> Of course. My question is more like "Nice functionality. But does it 
> carry it's own weight? Is the extra complexity worth it?"
Oh, yes. Over all the bragging about the nice
features I forgot the most important point:
If a developer goes to some length to write
unit tests, we should help her/him by flagging deprecated methods in 
unit tests.
Striving for quality should be supported.

The easiest way to implement this,
is to signal a warning (or any other exception).
The remainder -- invoking the pre-debugger -- is just the standard 
behavior for warnings.
(Besides, I see not much sense in displaying
6 stack frames on the transcript, when we
already have a perfect tool for that purpose,
namely the (pre-)debugger).
It would be better if the transcript, would
just display the method and a hint about the preference:
#openDebuggerOnDeprecationWarning .
A hint on how to avoid the deprecated message,
is also useful:

someOldSlowMethod
   "Bla bla bla ..."

   self deprecationWarning: 'Use new #newSpiffy'


However I left it that way, to be compatible
with the old behavior.

In a nutshell: The most important feature is
support for unit tests, the remainder were
low hanging fruits: easy to implement.

> 
>>
>> BTW, I took care that deprecated methods show up in unit tests as 
>> errors; unless suppressed
>> by -- you may have guessed it - changing a preference value. 
>> (#flagDeprecationWarningsAsUnitTestError)
>>
>>
>> HTH,
>>
>> Gerald
> 
> Thanks,
>