[Cuis-dev] Some enhancements

Thu May 25 06:41:19 PDT 2023

It’s not a user choice, it depends on the test implementation. I think it
doesn’t make sense to complicate the user interface to let users choose.

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

> 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/e046afea/attachment-0001.htm>