[Cuis-dev] Some enhancements

Luciano Notarfrancesco luchiano at gmail.com
Wed May 24 15:14:32 PDT 2023


Also note that in your changes (and also before, in the method I changed)
you send setUpResources and tearDownResources to the original instance, not
the new one..

On Wed, 24 May 2023 at 23:14 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230525/a74b56bf/attachment-0001.htm>


More information about the Cuis-dev mailing list