[Cuis-dev] Some enhancements

Hernán Wilkinson hernan.wilkinson at 10pines.com
Wed May 24 15:46:02 PDT 2023


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230524/ec0b9457/attachment.htm>


More information about the Cuis-dev mailing list