[Cuis-dev] Enhancement proposal: Fail test when no assertion ran
Andres Valloud
ten at smallinteger.com
Mon Apr 15 11:18:55 PDT 2024
There are actual examples of Error subclasses intended to rely on the
default handler. For example, there used to be a Smalltalk system which
had an exception for failure to open a file due to not enough file
handles. The default handler would then trigger finalization of files
that were already closed to release file handles, and then it would try
again. That was the point.
By having on:do:, yes, you can have contextualized handlers, but when
you write on: Error do: [...] that context is lost and instead becomes
dogma. What that code is saying is "I know much better than anyone else
because I know how *every conceivable error, even the ones I never saw*
should work here". That's the God mode position, might as well throw in
global variables too.
On 4/15/24 4:33 AM, Hernán Wilkinson via Cuis-dev wrote:
> I do not agree with your point of view.
> The on:do: message allows you to have contextual handlers, the default
> handler is a kind of global one that knows nothing about the dynamic
> context and how to handle the particular problem the excepcion was
> signaled for.
> Most of default handlers in Smalltalk are coupled with the UI and make
> incorrect assumptions of applicability. Look at the defaultAction of
> UndeclaredVariable or UndefinedVariable, etc. They assume you are in a
> browser, but what happens if you are filing in code?
>
> Hernan.
>
> On Sun, Apr 14, 2024 at 10:52 PM Andres Valloud via Cuis-dev
> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
>
> Speaking of this, observe the multitude of occurrences of
>
> on: Error do: [...]
>
> in the currently shipping code, and even in tests. This is almost
> certainly bad because said exceptions could have had a default handler
> to take care of the error in question. By doing on: Error do: [...],
> the code says "if any error at all occurs, then I know better than the
> default handler of said error". Handling errors by hand negates the
> point of having default handlers and misses the point. In the vast
> majority of cases, that should be
>
> on: UnhandledException do: [...]
>
> instead. But that is what SUnit is (ought to be) doing for you, so you
> do not have to type it yourself.
>
> On 4/3/24 3:51 PM, Andres Valloud via Cuis-dev wrote:
> > If we go by "agreement" of others, well that's the logical
> fallacy of
> > appeal to authority or majority. Most already think we shouldn't be
> > using Smalltalk, too. There's a lot more to it than that.
> >
> > The real problems of the world are more related to nobody having the
> > time to properly review code because there's too much of it, and the
> > fact that nobody needs a professional license to write software.
> More
> > boilerplate is not going to help, and that has consequences. For
> > example, this
> >
> > https://www.theregister.com/2024/04/01/xz_backdoor_open_source/
> <https://www.theregister.com/2024/04/01/xz_backdoor_open_source/>
> >
> > happened by packaging malicious code in tests.
> >
> > Why can't we agree that our testing framework declares that
> unhandled
> > exceptions are always bad, because they are? Why should anyone
> have to
> > write code to say that again?
> >
> > On 4/3/24 10:34 AM, Hernán Wilkinson wrote:
> >> That is a good point, but there is an "agreement" around the
> automatic
> >> testing people on making explicit that you are not expecting an
> >> exception, differentiate that test from the ones that do not have
> >> assertions by mistake.
> >> I do believe it is better to do it that way, it makes explicit what
> >> you are expecting and if the framework testing changes (like in
> this
> >> case is suggested), the test will continue working.
> >> I think that explicit is better than implicit in many areas,
> >> programming languages is one of them; python has that as a rule for
> >> example.
> >> I think making explicit that you are not expecting an exception
> to be
> >> signaled is better than not doing it.
> >>
> >> Hernan.
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Apr 3, 2024 at 2:22 PM Andres Valloud via Cuis-dev
> >> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>
> <mailto:cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>>> wrote:
> >>
> >> No, you can write code in a test method with the expectation
> that it
> >> will not raise unhandled exceptions, and you do not need
> >> assertions for
> >> that. Specifically, you do not need to write the silly
> >>
> >> shouldnt: [...] raise: UnhandledException
> >>
> >> because that's what SUnit is there for. You do not know a
> priori
> >> what
> >> the code writer is doing, so the tool should not guess.
> >>
> >> On 4/3/24 7:42 AM, Juan Vuletich via Cuis-dev wrote:
> >> > a test without assertions is not a test.
> >> -- Cuis-dev mailing list
> >> Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
> <mailto:Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>>
> >> https://lists.cuis.st/mailman/listinfo/cuis-dev
> <https://lists.cuis.st/mailman/listinfo/cuis-dev>
> >> <https://lists.cuis.st/mailman/listinfo/cuis-dev
> <https://lists.cuis.st/mailman/listinfo/cuis-dev>>
> >>
> >>
> >>
> >> --
> >> *Hernán Wilkinson
> >> Agile Software Development, Teaching & Coaching*
> >> *Phone: +54-011*-4893-2057
> >> *Twitter: @HernanWilkinson*
> >> *site: http://www.10Pines.com <http://www.10Pines.com>
> <http://www.10pines.com/ <http://www.10pines.com/>>*
> >> Address: Alem 896, Floor 6, Buenos Aires, Argentina
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
> https://lists.cuis.st/mailman/listinfo/cuis-dev
> <https://lists.cuis.st/mailman/listinfo/cuis-dev>
>
>
>
> --
> *Hernán Wilkinson
> Agile Software Development, Teaching & Coaching*
> *Phone: +54-011*-4893-2057
> *Twitter: @HernanWilkinson*
> *site: http://www.10Pines.com <http://www.10pines.com/>*
> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>
More information about the Cuis-dev
mailing list