[Cuis-dev] Some enhancements

Wed May 24 15:53:56 PDT 2023

I didn’t see anything about creating new instances or isolation in the
paper.
Anyway, how about creating a copy instead? ‘self copy’ instead of ‘self
class selector: testSelector’. That will work for me, does that work for
you?

On Thu, 25 May 2023 at 00:46 Hernán Wilkinson <hernan.wilkinson at 10pines.com>
wrote:

> Iit is a well know/assumed characteristic of tests to be isolated… if you
> read the sunit paper you will see kent beck defining that (i think it was
> in that paper, now i’m not sure…) and all tests frameworks use thet
> characteristic …
> It is not me but the culture around testing that defined that 🤷‍♂️
>
> On Wed, 24 May 2023 at 18:16 Luciano Notarfrancesco <luchiano at gmail.com>
> wrote:
>
>> Sure, I’ve been doing that for years. But really, I think there’s nothing
>> wrong with running a test several times, to me it is more weird assuming
>> that a new instance of exactly the same test can be created doing ‘aTest
>> class selector: testSelector’, that assumes a lot about what a test is and
>> how it is implemented, while the runner could assume much less and just
>> think of a test as something that understands setUp/run/tearDown.
>> But well, no problem…
>>
>> On Wed, 24 May 2023 at 23:07 Hernán Wilkinson <
>> hernan.wilkinson at 10pines.com> wrote:
>>
>>> Hi Luciano,
>>>  I understand your point but it is also true that some tests and people
>>> may not want to reuse the instance.
>>>  I think we should provide both options then. In your case you could
>>> redefine debug and debugAsFailure in the class you need that behavior or we
>>> could create a subclass of TestCase that redefines them for all the test
>>> cases that have to have that behaviour to subclass it.
>>>  What do you think?
>>>
>>> On Wed, May 24, 2023 at 6:02 PM Luciano Notarfrancesco <
>>> luchiano at gmail.com> wrote:
>>>
>>>> Hi Hernan,
>>>> Right, the thing about creating new instances of the test cases…
>>>> I think that conceptually it’s not wrong to reuse the instances, the
>>>> only problem is people programming incorrect tests that are not consistent
>>>> between multiple cycles of setUp/run/tearDown. I need to reuse instances
>>>> because I have tests that can be configured in different ways, for example
>>>> a test for polynomials that can run on polynomials over different rings.
>>>> And I also use randomness when initializing a test, so if you create a
>>>> new instance it will be initialized differently and it wouldn’t be
>>>> reproducible (for example a test fails, and when I click to debug it it
>>>> will be another instance that maybe won’t fail anymore). My tests are
>>>> completely deterministic, but what I call a “test” is an instance, not the
>>>> class, different instances can be different tests, a test is not
>>>> necessarily uniquely determined by the class and the selector. In fact,
>>>> that’s what happens with parameterized tests that can be configured to test
>>>> different things, like polynomials over the integers or polynomials over a
>>>> finite field, etc.
>>>> I don’t think this could affect other people’s tests, and I think tests
>>>> are more useful without the restriction that we had before, as it opens
>>>> more possibilities like the two examples I just mentioned. And as I said,
>>>> maybe some test that is not properly programmed to be consistent between
>>>> multiple cycles of setUp/run/tearDown could fail, but if that happens you
>>>> should be happy, because then the problem shows up and you can fix it.
>>>> My 2 cents,
>>>> Luciano
>>>>
>>>> On Wed, 24 May 2023 at 22:20 Hernán Wilkinson <
>>>> hernan.wilkinson at 10pines.com> wrote:
>>>>
>>>>> Hi Luciano
>>>>>  great changes to the runner!! I like them!
>>>>>  I have a few comments:
>>>>> 1) The changes in TestCase>>#debug and
>>>>> TestCase>>#debugAsFailureIfCanNot: can generate invalid results. The idea
>>>>> when running/debugging a test is not to reuse the previous instance of the
>>>>> test but to create a new one. Doing so the tests run isolated. Reusing the
>>>>> same instance can generate erratic results.
>>>>> 2) I fixed runSuiteProfiled:. It was doing:
>>>>> ...
>>>>> self changed: #runTests ]]] newProcess.
>>>>> ...
>>>>> And it should do:
>>>>> ...
>>>>>    self changed: #runTests; changed: #isRunning; changed:
>>>>> #isNotRunning. ]]] newProcess.
>>>>> ....
>>>>> as runSuite:
>>>>> (I also extracted those methods to one)
>>>>> 3) I fixed a bug when running profiled an empty list of tests.
>>>>>
>>>>> I'm attaching a .cs for those changes. I hope you agree with them.
>>>>>
>>>>> Also, why did you remove the SUnit from the laben/menu? I'd like it to
>>>>> say "SUnit" for historical reasons ... and there could be runners of other
>>>>> types of tests... Do you mind if we go back to "SUnit ..."?
>>>>>
>>>>> Cheers!
>>>>> Hernan.
>>>>>
>>>>> On Wed, May 24, 2023 at 1:01 PM Luciano Notarfrancesco via Cuis-dev <
>>>>> cuis-dev at lists.cuis.st> wrote:
>>>>>
>>>>>> Here's some changes for your consideration.
>>>>>> 1) Updated the commands to enter unicode characters with \;
>>>>>> 2) Added cmd-A shortcut to deselect all in the change list (analogous
>>>>>> to cmd-a for select all);
>>>>>> 3) Sort the messages in the browser message list with binary messages
>>>>>> at the top;
>>>>>> 4) Reworked the test runner.
>>>>>>
>>>>>> The biggest change is the last one. I simplified the test runner
>>>>>> window, added shortcuts for everything (cmd-a/A for select/deselect all,
>>>>>> cmd-r for run, cmd-o for run one, cmd-l for canceling a run, etc), and
>>>>>> fixed redrawing/update problems and some other bugs. Now the lists of error
>>>>>> and failing tests are updated while the tests are running, and clicking on
>>>>>> an item from those lists stops the current run and debugs the item
>>>>>> immediately.
>>>>>> I use the test runner a lot, I run 5k tests on my project every time
>>>>>> I change anything and it takes some minutes. I think these changes make the
>>>>>> test runner more useful and less painful, let me know what you think.
>>>>>> --
>>>>>> Cuis-dev mailing list
>>>>>> Cuis-dev at lists.cuis.st
>>>>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Hernán WilkinsonAgile 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
>>>>>
>>>>
>>>
>>> --
>>>
>>> *Hernán WilkinsonAgile 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
>>>
>> --
>
> *Hernán WilkinsonAgile 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230525/4c7224d8/attachment.htm>