About deprecation and unit testing

http://stackoverflow.com/questions/20369972/about-deprecation-and-unit-testing-in-pharo

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

On 04 Dec 2013, at 08:57, Damien Cassou <[hidden email]> wrote:

> http://stackoverflow.com/questions/20369972/about-deprecation-and-unit-testing-in-pharo
>

There is a related bug tracker entry:

11423 Running unit tests that raise deprecation warnings makes them fail incomprehensibly
        https://pharo.fogbugz.com/f/cases/11423

You could do:

[ 'foobar' asFileReference ensureDeleted ]
  on: Deprecation
  do: [ :exception | exception resume ]

On 04 Dec 2013, at 08:57, Damien Cassou <[hidden email]> wrote:

On Wed, Dec 4, 2013 at 9:18 AM, Marcus Denker <[hidden email]> wrote:
> There is a related bug tracker entry:


I will try to propose a slice that ignores deprecation warnings while
running the tests. But this will make it harder for people to find
deprecated message sends.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

On 04 Dec 2013, at 09:33, Damien Cassou <[hidden email]> wrote:

> On Wed, Dec 4, 2013 at 9:18 AM, Marcus Denker <[hidden email]> wrote:
>> There is a related bug tracker entry:
>
>
> I will try to propose a slice that ignores deprecation warnings while
> running the tests. But this will make it harder for people to find
> deprecated message sends.

No, I wouldn’t do that by default: that would defeat the whole purpose of deprecation. If you want to ignore deprecations, you should do it yourself in your own tests, at your own risk, IMHO.

> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm."
> Winston Churchill
>

On Wed, Dec 4, 2013 at 9:50 AM, Sven Van Caekenberghe <[hidden email]> wrote:
> No, I wouldn’t do that by default: that would defeat the whole purpose of deprecation. If you want to ignore deprecations, you should do it yourself in your own tests, at your own risk, IMHO.


what about:

- when the preference #raiseWarning: is true, a test sending a
deprecated message fails
- when the preference #raiseWarning: is false, a test sending a
deprecated message succeeds

Implemented in:

Name: SLICE-Issue-11423-Running-unit-tests-that-raise-deprecation-warnings-makes-them-fail-incomprehensibly-DamienCassou.1
Author: DamienCassou
Time: 4 December 2013, 9:56:07.727774 am
UUID: bc043b07-b57b-4b5c-b140-8805a4397d31
Ancestors:
Dependencies: SUnit-Tests-DamienCassou.31, SUnit-Core-DamienCassou.107

- when the preference #raiseWarning: is true, a test sending a
deprecated message fails
- when the preference #raiseWarning: is false, a test sending a
deprecated message succeeds



--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

On 04 Dec 2013, at 09:56, Damien Cassou <[hidden email]> wrote:

OK, that sounds reasonable, Damien.

>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm."
> Winston Churchill
>

A related issue is the enforcing of protocol. Currently, the RPackage implementation
doesn’t allow other class-side definitions of #packages. There was no test for that,
so all images with Grease loaded (all Moose & Seaside based images) fail silently.
In Slice 12324 I added a test checking that no class below Object redefines the method.

Stephan

On 04 Dec 2013, at 11:47, Stephan Eggermont <[hidden email]> wrote:

> A related issue is the enforcing of protocol. Currently, the RPackage implementation
> doesn’t allow other class-side definitions of #packages. There was no test for that,
> so all images with Grease loaded (all Moose & Seaside based images) fail silently.
> In Slice 12324 I added a test checking that no class below Object redefines the method.
>

this is true for all meta kind of selectors… e.g. #layout… (there is an issue related to that)

        Marcus

> A related issue is the enforcing of protocol. Currently, the RPackage implementation
> doesn’t allow other class-side definitions of #packages. There was no test for that,
> so all images with Grease loaded (all Moose & Seaside based images) fail silently.
> In Slice 12324 I added a test checking that no class below Object redefines the method.

I do not think that it can be correct because ClassDecription defines it and it is under Object

Stef wrote
>I do not think that it can be correct because ClassDecription defines it and it is under Object

I wasn’t precise enough. This is the current test.

        self assert: (Object allSubclasses select: [: each | (each class compiledMethodAt: #packages ifAbsent: [nil]) isNotNil]) isEmpty.

It found the 5 (not 4, I missed one) extra implementations.

Stephan

Luc Fabresse wrote:

Hi All,

 

 I think that trapping Deprecations silently is not a good idea.

 As you said, people will not see them and it will be hard to upgrade code.

 Why not having a Preference?

 or another button in the TestRunner such as: "Run ignoring Deprecation"?

 

#Luc

2013/12/4 Damien Cassou <[hidden email]>

On Wed, Dec 4, 2013 at 9:18 AM, Marcus Denker <[hidden email]> wrote:
> There is a related bug tracker entry:

I will try to propose a slice that ignores deprecation warnings while
running the tests. But this will make it harder for people to find
deprecated message sends.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

Or adding a new reported category "Deprecations" to go with "Expected Failure"

Hi guys,

Deprecation is a subclass of Warning, not Error. And I think this is
absolutely correct.

So the basic question here is if the action on Warnings and
Notifications in general in SUnit is correct or should be changed.
This is not necessarily limited to Deprecation.

Of course we need a possibility to test assertions about Deprecations
and other Notifications as well, so it sure is not a good idea to make
"transparent" changes and simply ignore Deprecation or any other kind of
Notification/Warning.

Just my 2 cents

Joachim


Am 05.12.13 10:41, schrieb [hidden email]:

--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1