[Cuis-dev] Some enhancements

Thu May 25 06:35:44 PDT 2023

What about implementing the messages #debugInSameInstance and changing the
runner window in such a way to send  #debugInSameInstance if you do
shift-click on the failed test and #debug if you do click as currently
works?
If we do this you will not have to change or implement special messages in
your code, just press a different key to debug the test using the same
instance.

On Thu, May 25, 2023 at 2:20 AM Luciano Notarfrancesco <luchiano at gmail.com>
wrote:

> How about this new version? I use copy, but I implemented copy with the
> original behaviour. I'd prefer to not include this #copy method in the
> change set, you can remove it if you agree, but it's ok for me if you
> prefer to include it to keep the exact original behaviour... it makes more
> sense for me to redefine copy in a subclass rather than being forced to
> "hack" it by redefining debug and debugAsFailure. What do you think?
>
> On Thu, May 25, 2023 at 6:53 AM Luciano Notarfrancesco <luchiano at gmail.com>
> wrote:
>
>> 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
>>>
>>

-- 

*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/56be195d/attachment-0001.htm>