[Cuis-dev] Some enhancements

Wed May 24 14:14:32 PDT 2023

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/20230524/866e1974/attachment.htm>