[Cuis-dev] Some enhancements

Fri May 26 04:50:05 PDT 2023

Great, I modified my tests (took me a couple of hours, I have too many) and
everything works as expected. Thanks!

On Fri, 26 May 2023 at 01:24 Hernán Wilkinson <hernan.wilkinson at 10pines.com>
wrote:

> Great!
> I just pushed your cs to github and another to rename #copy to
> #debugInstance
>
> Cheers!
> Hernan.
>
> On Thu, May 25, 2023 at 12:02 PM Luciano Notarfrancesco <
> luchiano at gmail.com> wrote:
>
>> Sure, that works for me. I’ll just implement that method in my
>> RandomizedTestCase to call super and then setSeed: seed, so it doesn’t
>> loose determinism.
>>
>> On Thu, 25 May 2023 at 16:54 Hernán Wilkinson <
>> hernan.wilkinson at 10pines.com> wrote:
>>
>>> I thought you did not want to change the code/implement a method just
>>> for this.
>>> If that is not a problem then the code you sent with the #copy is fine
>>> for me, although I would change #copy for #debugInstance because copy has a
>>> well defined behavior and the default implementation would not do what copy
>>> is expected to do.
>>> Let me know if that is ok with you
>>>
>>> Hernan.
>>>
>>> On Thu, May 25, 2023 at 10:41 AM Luciano Notarfrancesco <
>>> luchiano at gmail.com> wrote:
>>>
>>>> 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
>>>>>
>>>>
>>>
>>> --
>>>
>>> *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/20230526/02096352/attachment-0001.htm>